Project

General

Profile

Make a new release » History » Version 32

msuraev, 08/28/2017 09:12 AM

1 22 msuraev
{{>toc}}
2
3 2 neels
h1. Make a new release
4 1 neels
5 13 msuraev
The efforts to automate the release process are tracked in https://projects.osmocom.org/issues/1861
6
7 17 msuraev
h2. When to make a new release
8 1 neels
9 16 msuraev
Various Osmocom projects depend on others.
10 1 neels
11 28 msuraev
*FIXME:* following part is disputable and should be fixed
12 29 msuraev
13 16 msuraev
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:
14
15 1 neels
Among others, @openbsc@ depends on the libraries built from @libosmocore@, for example @libosmogsm@.
16
As soon as the @libosmogsm@ library gets a new feature used by @openbsc@, like something was added to
17
@gsm_utils.h@, we shall
18 6 neels
* tag a release in @libosmocore@; say if the previous version was 0.1.2, make it at least 0.1.3.
19 1 neels
* and in @openbsc@, require @libosmogsm@ >= 0.1.3 in @configure.ac@
20 16 msuraev
21 28 msuraev
*Proposed policy:*
22 16 msuraev
* master branch is expected to depend on latest master branches of depended-upon projects
23 24 msuraev
* make release of depended-upon projects if necessary before making non-library project release
24
* make sure that we have correct version dependencies before making non-library project release
25 1 neels
26 25 msuraev
Alternatively/additionally we can make timely releases (once per XX months? before every OsmoDevCon?) of non-library projects (and corresponding depended-upon libraries) to avoid batching too many changes together and to adhere to RERO better - see http://scalare.org/wp-content/uploads/2015/06/2015-Why-and-HowShould-OpenSource-ProjectsAdopt-Time-Based-Releases.pdf
27 20 msuraev
28 17 msuraev
h2. How to make a new release
29
30 30 msuraev
First we outline specific steps, than common for different project types.
31
32 17 msuraev
h3. Library release
33
34 30 msuraev
* modify @*_LIBVERSION@ in @Makefile.am@ as necessary according to TODO-RELEASE file
35 1 neels
36
h3. Non-library release
37
38 30 msuraev
* nothing special is required ATM
39 1 neels
40 30 msuraev
h3. Common steps
41 1 neels
42 30 msuraev
Be default @make release@ prepares 'patch' release but you can manually specify any of 'major/minor/patch' as necessary - see http://semver.org/ for details.
43 1 neels
44 30 msuraev
* run @make REL=minor release@
45
* inspect the latest commit which was just created
46 32 msuraev
* adjust it if necessary and re-sign (see [[Make_a_new_release#How-to-retag-a-new-release|Re-tag new release]])
47 30 msuraev
* push commit for review using @git review -f@ (see [[Gerrit]] for alternatives)
48
* push the release tag by @git push gerrit --tags@
49 1 neels
50 30 msuraev
h3. How to (re)tag a new release
51 1 neels
52 30 msuraev
* run @git tag -s 0.4.0 -f -m "Release v0.4.0 on 2017-08-25."@
53
54
This will automatically (re)sign the latest commit. You can specify which commit to sign explicitly.
55 3 neels
56 1 neels
Say, for example, the git hash is @012342abcdefg@ and the next open version is 0.1.3:
57 9 neels
<pre>
58 1 neels
git tag -s 0.1.3 012342abcdefg -m "release 0.1.3"
59
</pre>
60 8 neels
61 1 neels
(If @gpg@ complains, see [[Make a new release#GPG-Have-a-matching-user-id|GPG: Have a matching user id]].)
62 4 neels
63 1 neels
Verify that git picks up the new version tag:
64
<pre>
65
$ git describe
66
0.1.3-3-g1f95179
67
</pre>
68 11 neels
69
*For your local build, _nothing will change_ until you delete the @.version@ file
70
and completely rebuild:*
71 1 neels
72
<pre>
73 10 neels
rm .version
74
autoreconf -fi
75 1 neels
./configure
76
make
77
cat .version
78
</pre>
79
80
This should show the same as @git describe@.
81
82
When you're convinced that all is in order, push the new tag:
83
84
<pre>
85
git push origin 0.1.3
86
</pre>
87 14 neels
88 1 neels
If anything went wrong, you can delete the tag (locally) by
89 15 msuraev
<pre>
90 14 neels
git tag -d 0.1.3
91
</pre>
92
and, if you've already pushed it, by
93
<pre>
94
git push --delete origin 0.1.3
95 1 neels
</pre>
96 26 msuraev
97
h2. Deprecation policy
98 27 msuraev
99 26 msuraev
Functions/interfaces marked as deprecated for X releases of type Y can be removed in next Z release.
100 27 msuraev
101 26 msuraev
TBD: what's appropriate value for X? which Y and Z (from major/minor/patch) should we use?
102 1 neels
103
h2. GPG: Have a matching user id
104
105
By default, @git tag -s@ takes your author information to lookup the secret GPG key to sign a tag with.
106
If the author+email do not exactly match one of the key's @uid@s, you will get this error:
107
108
<pre>
109
gpg: signing failed: secret key not available
110
</pre>
111
112
Verify: say, your author+email info in your git config says "John Doe <john@doe.net>", try
113
<pre>
114
gpg --list-secret-keys "John Doe <john@doe.net>"
115
</pre>
116
If this fails, GPG won't find the right key automatically.
117
118
Ways to resolve:
119
120
* Use @git tag -u <key-id>@
121
* Edit your secret key to add a uid that matches your author information
122
<pre>
123
gpg --edit-key john@doe.net
124
gpg> adduid
125
# enter details to match the git author
126
gpg> save
127
</pre>
Add picture from clipboard (Maximum size: 48.8 MB)