- Table of contents
- Make a new release
- When to make a new release
- Versioning considerations for libraries
- How to make a new release
- Which new release to make
- Deprecation policy
- How to (re)tag a new release
- GPG: Have a matching user id
- Dependency graph
Make a new release¶
The efforts to automate the release process are tracked in https://projects.osmocom.org/issues/1861
When to make a new release¶
Various Osmocom projects depend on others.Proposed policy:
- master branch is expected to depend on latest master branches of depended-upon projects
- make release of depended-upon projects if necessary before making non-library project release
- make sure that we have correct version dependencies before making non-library project release
- once per XX months?
- before every OsmoDevCon?
- once YY items accumulated in TODO-RELEASE file(see TODO-RELEASE file format)
- when configuration/db format changes?
This would help to avoid batching too many changes together and to adhere to RERO better - see 2015-Why-and-HowShould-OpenSource-ProjectsAdopt-Time-Based-Releases.pdf
Versioning considerations for libraries¶
Every osmocom library is built using libtool's version-info system. This system format and algorithm to update the versions is documented in here.
However, debian packaging system follows a different versioning convention, but conveniently the debian versioning system can be deduced from libtool's version-info. More information can be found in here.
Specially interesting is the warning section:
A common mistake is to assume that the three values passed to -version-info map directly into the three numbers at the end of the library name. This is not the case, and indeed, current, revision and age are applied differently depending on the operating system that one is using.
For Linux, for instance, while the last two values map directly from the command-line, the first is calculated by subtracting age from current. On the other hand, on modern FreeBSD, only one component is used in the library version, which corresponds to current.
Summary: For libtool's system
current:revision:age, it gets translated into version number
major=current-age, reflecting the fact that ABIs can be backwards compatible. Debian uses
major to generate the package name.
The following command, when run on a shared library, will output the name to be used for the Debian package containing that shared library:
objdump -p library.so \ | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' \ | LC_ALL=C sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/'
osmo-release.mk helper (installed by
libosmocore-dev) available via
make release takes care of
- version bump
- debian/changelog update
Feel free to send patches implementing further automation as you see fit.
You can alternatively run osmo-release.mk directly from your git repo in /foo/bar/libosmocore by using:
PATH="$PATH:/foo/bar/libosmocore" make REL=minor release --include-dir="/foo/bar/libosmocore"
osmo-release.mkrequires several extra dependencies. Make sure you have them installed in your system:
TODO-RELEASE file format and maintenance¶
- all the strings which contain
#considered comment and will be ignored
- actual entries consists of 3 tab-separated fields:
- library - name of the library affected (should correspond to
lib*.pc.infile in project's root directory)
- what - API or ABI change (used as a guidance to properly bump
- description - textual description (will end up in changelog)
When change affecting library's API/ABI is made then new entry should be added to TODO-RELEASE according to the format above. The file will be claned-up automatically by
make release command.
How to make a new release¶
First we outline specific steps for different project types, then common part.
Extra steps for Libraries¶
Some extra previous steps are required if the project installs a public shared library.
src/Makefile.amas necessary according to TODO-RELEASE file
- if necessary ("current/age" component of
*_LIBVERSIONwas bumped) then rename
debian/lib*.installto match the change. See Versioning considerations for libraries.
- if necessary (any of
debian/lib*.installwere renamed) then adjust
debian/controlaccordingly. Specifically look for "Package" and "Depends" attributes.
- Some projects (osmo-ggsn) also state the library version in dh_strip lines in
debian/rules. That one needs to be updated too to match the new library version.
The release helper is trying to be smart about it and prevent making new library release with non-empty TODO-RELEASE file if
*_LIBVERSION is not adjusted beforehand.
make release prepares 'patch' release but you can manually specify any of 'major/minor/patch' as necessary - see http://semver.org/ for details.
- Make sure all the changes you want in the release commit are staged (
make REL=minor release
- an editor will be opened in case you want to reword the release commit. Useful if you want to add any remarks on the actions taken.
- inspect the latest commit which was just created
- adjust it if necessary and re-sign (see Re-tag new release)
- push commit for review to gerrit and ask somebody to review and merge it quickly (to avoid other commits being merged in between).
- Once merged, make sure the merged release commit did not change (due to in-between merges), thenpush the release tag by
git push gerrit --tags
- consider preparing article for https://osmocom.org/news/ and sending announcement to appropriate ML for major release once release commit passed the review
git tag -d TAG_JUST_CREATED
git reset --soft HEAD^
git reset HEAD debian/changelog && git checkout debian/changelog
- Do your modifications
- Proceed again with the release steps listed above
Which new release to make¶Use following guidelines when choosing release type:
- major - ?? TBD
- minor - ?? TBD
- patch - ?? TBD
If unsure - ask in corresponding ML.
Functions/interfaces marked as deprecated for X releases of type Y can be removed in next Z release.
TBD: what's appropriate value for X? which Y and Z (from major/minor/patch) should we use?
How to (re)tag a new release¶
This might be necessary if previous release was made manually with some mistakes which have to be corrected and amended to the release commit.
git tag -s 0.4.0 -f -m "Release v0.4.0 on 2017-08-25."
This will automatically (re)sign the latest commit. You can specify which commit to sign explicitly.
Say, for example, the git hash is
012342abcdefg and the next open version is 0.1.3:
git tag -s 0.1.3 012342abcdefg -m "release 0.1.3"
gpg complains, see GPG: Have a matching user id.)
Verify that git picks up the new version tag:
$ git describe 0.1.3-3-g1f95179
N. B: For your local build, nothing will change until you delete the
.version file and completely rebuild:
rm .version autoreconf -fi ./configure make cat .version
This should show the same as
When you're convinced that all is in order, push the new tag:
git push origin 0.1.3
If anything went wrong, you can delete the tag (locally) by
git tag -d 0.1.3
and, if you've already pushed it, by
git push --delete origin 0.1.3
GPG: Have a matching user id¶
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 <email@example.com>", try
gpg --list-secret-keys "John Doe <firstname.lastname@example.org>"
If this fails, GPG won't find the right key automatically.
Ways to resolve:
git tag -u <key-id>
- Edit your secret key to add a uid that matches your author information
gpg --edit-key email@example.com gpg> adduid # enter details to match the git author gpg> save
This section aims at providing a dependency graph of the osmocom cellular network infrastructure projects in case a cascade of releases is intended: