Make a new release » History » Revision 13
Revision 12 (msuraev, 12/14/2016 12:41 PM) → Revision 13/115 (msuraev, 12/14/2016 12:46 PM)
h1. Make a new release
The efforts to automate the release process are tracked in https://projects.osmocom.org/issues/1861
h2. When to tag a new release
Various Osmocom projects depend on others. As soon as a feature is added to one Osmocom project that is needed for another dependent project to compile, we should tag at least a minor-revision bump in the depended-upon project and require it in the depending project's configure.ac. To illustrate, let's look at this example:
Among others, @openbsc@ depends on the libraries built from @libosmocore@, for example @libosmogsm@.
As soon as the @libosmogsm@ library gets a new feature used by @openbsc@, like something was added to
@gsm_utils.h@, we shall
* tag a release in @libosmocore@; say if the previous version was 0.1.2, make it at least 0.1.3.
* and in @openbsc@, require @libosmogsm@ >= 0.1.3 in @configure.ac@
h2. How to tag a new release
The revision to tag must be merged to the public, upstream @master@ branch.
Find out the git hash for the revision you want to tag.
Find out the next open version number. Take care: look at *all* of these:
* @git tag -l@
* debian/changelog
For example, the changelog may contain versions that were forgotten to be tagged.
Now, make a GPG-signed tag of that git hash with the next open version number.
Say, for example, the git hash is @012342abcdefg@ and the next open version is 0.1.3:
<pre>
git tag -s 0.1.3 012342abcdefg -m "release 0.1.3"
</pre>
(If @gpg@ complains, see [[Make a new release#GPG-Have-a-matching-user-id|GPG: Have a matching user id]].)
Verify that git picks up the new version tag:
<pre>
$ git describe
0.1.3-3-g1f95179
</pre>
*For your local build, _nothing will change_ until you delete the @.version@ file
and completely rebuild:*
<pre>
rm .version
autoreconf -fi
./configure
make
cat .version
</pre>
This should show the same as @git describe@.
When you're convinced that all is in order, push the new tag:
<pre>
git push origin 0.1.3
</pre>
If anything went wrong, you can delete the tag (locally) by
<pre>
git tag -d 0.1.3
</pre>
and, if you've already pushed it, by
<pre>
git push --delete origin 0.1.3
</pre>
h2. Make a Release
TODO: more detailed description of necessary release steps
* cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE)
* update debian/changelog using "gbp dch" command
* ???
* PROFIT
h2. GPG: Have a matching user id
By default, @git tag -s@ takes your author information to lookup the secret GPG key to sign a tag with.
If the author+email do not exactly match one of the key's @uid@s, you will get this error:
<pre>
gpg: signing failed: secret key not available
</pre>
Verify: say, your author+email info in your git config says "John Doe <john@doe.net>", try
<pre>
gpg --list-secret-keys "John Doe <john@doe.net>"
</pre>
If this fails, GPG won't find the right key automatically.
Ways to resolve:
* Use @git tag -u <key-id>@
* Edit your secret key to add a uid that matches your author information
<pre>
gpg --edit-key john@doe.net
gpg> adduid
# enter details to match the git author
gpg> save
</pre>