Keyringer: development guidelines and workflow
Index
Coding standards
- Uses Semantic Versioning.
- Respect the existing coding style.
- Be clear: easy audability must be one of keyringer's requirements.
Release workflow
Go to develop branch and start a new release
git checkout develop
Prepare the source code:
$EDITOR keyringer # and update KEYRINGER_VERSION
$EDITOR ChangeLog
VERSION="`./keyringer | head -n 1 | cut -d ' ' -f 2`"
Create and upload a new release:
make release
Tag the release:
git tag -s $VERSION -m "Keyringer $VERSION"
Update the debian branch:
make debian
Push everything:
git push --tags
Build the package from the debian Git branch:
gbp buildpackage
Run lintian (or add it to your pbuilder hooks):
lintian --info --display-info --pedantic --color auto build-area/keyringer_$VERSION*.changes
Then go back to the develop branch and push everything:
git checkout develop
git push --all
Cleanup symlink:
rm ../keyringer_$VERSION.orig.tar.bz2
Notes:
gbp import-origtakes care of runningpristine-tar commit, of merging of the tag and orig tarball into the upstream branch, and then it merges the result into the debian branch. With the above configuration, it also runs git-dch to do the bulk of the work indebian/changelog.- To build a development package, checkout the debian branch, merge master, run
git-dch --auto --snapshotand build.
Packaging workflow
We recommend this packaging workflow.
Adding or changing a subcommand
When adding a new subcommand or changing subcommand behavior, ensure:
- Documentation is updated.
- Manpage is updated.
- Shell completions are updated.
Test environment
Setup:
keyringer test init ~/temp/tests/keyringer
Teardown:
keyringer test teardown -y
Translation
Run just once:
cd share/man
po4a-gettextize -f text -m keyringer.1.mdwn -p keyringer.pot