Tag a new release¶

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 revision was 0.1.2, we make it at least 0.1.3.
• in openbsc, require libosmogsm >= 0.1.3 in configure.ac

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 tag revision. 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 revision with the next open revision number.

Say, for example, the git hash is 012342abcdefg and the next open tag is 0.1.3:

git tag -s 0.1.3 012342abcdefg

(If gpg complains, see below.)

Verify that git picks up the new revision tag:

$ git describe
0.1.3-3-g1f95179

For your local build, nothing will change until you delete .version:

rm .version
make
cat .version

This should show the same as git describe.

When you're convinced that all is in order, push the new tag:

git push origin 0.1.3

Make a Release¶

TODO: describe how to build and publish a release for real

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:

gpg: signing failed: secret key not available

Verify: say, your author+email info in your git config says "John Doe <john@doe.net>", try

gpg --list-secret-keys "John Doe <john@doe.net>" 

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
  

  gpg --edit-key john@doe.net
  gpg> adduid
  # enter details to match the git author
  gpg> save