Make a new release » History » Version 2
neels, 12/09/2016 10:13 PM
1 | 2 | neels | h1. Make a new release |
---|---|---|---|
2 | 1 | neels | |
3 | h2. When to tag a new release |
||
4 | |||
5 | 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: |
||
6 | |||
7 | Among others, @openbsc@ depends on the libraries built from @libosmocore@, for example @libosmogsm@. |
||
8 | As soon as the @libosmogsm@ library gets a new feature used by @openbsc@, like something was added to |
||
9 | @gsm_utils.h@, we shall |
||
10 | * tag a release in @libosmocore@, say if the previous revision was 0.1.2, we make it at least 0.1.3. |
||
11 | * in @openbsc@, require @libosmogsm@ >= 0.1.3 in @configure.ac@ |
||
12 | |||
13 | h2. How to tag a new release |
||
14 | |||
15 | The revision to tag must be merged to the public, upstream @master@ branch. |
||
16 | |||
17 | Find out the git hash for the revision you want to tag. |
||
18 | |||
19 | Find out the next open tag revision. Take care: look at *all* of these: |
||
20 | * @git tag -l@ |
||
21 | * debian/changelog |
||
22 | For example, the changelog may contain versions that were forgotten to be tagged. |
||
23 | |||
24 | Now, make a GPG-signed tag of that revision with the next open revision number. |
||
25 | |||
26 | Say, for example, the git hash is @012342abcdefg@ and the next open tag is 0.1.3: |
||
27 | <pre> |
||
28 | git tag -s 0.1.3 012342abcdefg |
||
29 | </pre> |
||
30 | |||
31 | (If @gpg@ complains, see below.) |
||
32 | |||
33 | Verify that git picks up the new revision tag: |
||
34 | <pre> |
||
35 | $ git describe |
||
36 | 0.1.3-3-g1f95179 |
||
37 | </pre> |
||
38 | |||
39 | For your local build, _nothing will change_ until you delete @.version@: |
||
40 | <pre> |
||
41 | rm .version |
||
42 | make |
||
43 | cat .version |
||
44 | </pre> |
||
45 | |||
46 | This should show the same as @git describe@. |
||
47 | |||
48 | When you're convinced that all is in order, push the new tag: |
||
49 | |||
50 | <pre> |
||
51 | git push origin 0.1.3 |
||
52 | </pre> |
||
53 | |||
54 | h2. Make a Release |
||
55 | |||
56 | TODO: describe how to build and publish a release for real |
||
57 | |||
58 | |||
59 | h2. GPG: Have a matching user id |
||
60 | |||
61 | By default, @git tag -s@ takes your author information to lookup the secret GPG key to sign a tag with. |
||
62 | If the author+email do not exactly match one of the key's @uid@s, you will get this error: |
||
63 | |||
64 | <pre> |
||
65 | gpg: signing failed: secret key not available |
||
66 | </pre> |
||
67 | |||
68 | Verify: say, your author+email info in your git config says "John Doe <john@doe.net>", try |
||
69 | <pre> |
||
70 | gpg --list-secret-keys "John Doe <john@doe.net>" |
||
71 | </pre> |
||
72 | If this fails, GPG won't find the right key automatically. |
||
73 | |||
74 | Ways to resolve: |
||
75 | |||
76 | * Use @git tag -u <key-id>@ |
||
77 | * Edit your secret key to add a uid that matches your author information |
||
78 | <pre> |
||
79 | gpg --edit-key john@doe.net |
||
80 | gpg> adduid |
||
81 | # enter details to match the git author |
||
82 | gpg> save |
||
83 | </pre> |