Make a new release » History » Version 21
msuraev, 07/06/2017 08:44 AM
1 | 2 | neels | h1. Make a new release |
---|---|---|---|
2 | 1 | neels | |
3 | 13 | msuraev | The efforts to automate the release process are tracked in https://projects.osmocom.org/issues/1861 |
4 | |||
5 | 17 | msuraev | h2. When to make a new release |
6 | 1 | neels | |
7 | 16 | msuraev | Various Osmocom projects depend on others. |
8 | 1 | neels | |
9 | 16 | msuraev | FIXME: following part is disputable and should be fixed |
10 | 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: |
||
11 | |||
12 | 1 | neels | Among others, @openbsc@ depends on the libraries built from @libosmocore@, for example @libosmogsm@. |
13 | As soon as the @libosmogsm@ library gets a new feature used by @openbsc@, like something was added to |
||
14 | @gsm_utils.h@, we shall |
||
15 | 6 | neels | * tag a release in @libosmocore@; say if the previous version was 0.1.2, make it at least 0.1.3. |
16 | 1 | neels | * and in @openbsc@, require @libosmogsm@ >= 0.1.3 in @configure.ac@ |
17 | 16 | msuraev | |
18 | Proposed policy: |
||
19 | * master branch is expected to depend on latest master branches of depended-upon projects |
||
20 | * make release of depended-upon projects if necessary before making project release |
||
21 | * make sure that we have correct version dependencies before making project release |
||
22 | 1 | neels | |
23 | 20 | msuraev | Alternatively/additionally we can make timely releases (once per XX months?) of projects (and corresponding depended-upon libraries) to avoid batching too many changes together and to adhere to RERO better. |
24 | |||
25 | 17 | msuraev | h2. How to make a new release |
26 | |||
27 | 21 | msuraev | h3. Library release |
28 | |||
29 | 17 | msuraev | Commit changes: |
30 | * cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE) |
||
31 | * update debian/changelog using @gbp dch --debian-tag='%(version)s' --auto@ command |
||
32 | 21 | msuraev | |
33 | h3. Non-library release |
||
34 | 17 | msuraev | |
35 | TODO: more detailed description of necessary release steps: |
||
36 | 19 | msuraev | create, sign, publish tarball, pushing via gerrit etc. |
37 | 17 | msuraev | |
38 | 18 | msuraev | h3. How to tag a new release |
39 | 1 | neels | |
40 | The revision to tag must be merged to the public, upstream @master@ branch. |
||
41 | |||
42 | Find out the git hash for the revision you want to tag. |
||
43 | |||
44 | 3 | neels | Find out the next open version number. Take care: look at *all* of these: |
45 | 1 | neels | * @git tag -l@ |
46 | * debian/changelog |
||
47 | For example, the changelog may contain versions that were forgotten to be tagged. |
||
48 | |||
49 | 3 | neels | Now, make a GPG-signed tag of that git hash with the next open version number. |
50 | 1 | neels | |
51 | 3 | neels | Say, for example, the git hash is @012342abcdefg@ and the next open version is 0.1.3: |
52 | 1 | neels | <pre> |
53 | 9 | neels | git tag -s 0.1.3 012342abcdefg -m "release 0.1.3" |
54 | 1 | neels | </pre> |
55 | |||
56 | 8 | neels | (If @gpg@ complains, see [[Make a new release#GPG-Have-a-matching-user-id|GPG: Have a matching user id]].) |
57 | 1 | neels | |
58 | 4 | neels | Verify that git picks up the new version tag: |
59 | 1 | neels | <pre> |
60 | $ git describe |
||
61 | 0.1.3-3-g1f95179 |
||
62 | </pre> |
||
63 | |||
64 | 11 | neels | *For your local build, _nothing will change_ until you delete the @.version@ file |
65 | and completely rebuild:* |
||
66 | |||
67 | 1 | neels | <pre> |
68 | rm .version |
||
69 | 10 | neels | autoreconf -fi |
70 | ./configure |
||
71 | 1 | neels | make |
72 | cat .version |
||
73 | </pre> |
||
74 | |||
75 | This should show the same as @git describe@. |
||
76 | |||
77 | When you're convinced that all is in order, push the new tag: |
||
78 | |||
79 | <pre> |
||
80 | git push origin 0.1.3 |
||
81 | </pre> |
||
82 | |||
83 | 14 | neels | If anything went wrong, you can delete the tag (locally) by |
84 | 1 | neels | <pre> |
85 | 15 | msuraev | git tag -d 0.1.3 |
86 | 14 | neels | </pre> |
87 | and, if you've already pushed it, by |
||
88 | <pre> |
||
89 | git push --delete origin 0.1.3 |
||
90 | </pre> |
||
91 | 1 | neels | |
92 | h2. GPG: Have a matching user id |
||
93 | |||
94 | By default, @git tag -s@ takes your author information to lookup the secret GPG key to sign a tag with. |
||
95 | If the author+email do not exactly match one of the key's @uid@s, you will get this error: |
||
96 | |||
97 | <pre> |
||
98 | gpg: signing failed: secret key not available |
||
99 | </pre> |
||
100 | |||
101 | Verify: say, your author+email info in your git config says "John Doe <john@doe.net>", try |
||
102 | <pre> |
||
103 | gpg --list-secret-keys "John Doe <john@doe.net>" |
||
104 | </pre> |
||
105 | If this fails, GPG won't find the right key automatically. |
||
106 | |||
107 | Ways to resolve: |
||
108 | |||
109 | * Use @git tag -u <key-id>@ |
||
110 | * Edit your secret key to add a uid that matches your author information |
||
111 | <pre> |
||
112 | gpg --edit-key john@doe.net |
||
113 | gpg> adduid |
||
114 | # enter details to match the git author |
||
115 | gpg> save |
||
116 | </pre> |