Hi.
So far releases of Osmocom project were rather rare and without any schedule. It would be nice to change that but to do that we've got to make the process of making a release as smooth as possible.
The ticket which tracks this activity: https://projects.osmocom.org/issues/1861
What we have right now: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
What I've implemented: https://gerrit.osmocom.org/#/c/3130/
The TLDR:
we type "make REL=minor release" and get:
* signed and tagged commit
* automated version bump
* updated debian/changelog
Longer explanation:
That's implemented as separate makefile which is installed as part of libosmocore-dev and can be re-used by other projects in few lines (see https://gerrit.osmocom.org/#/c/3131/ for example).
It treats libraries separately from non-library projects (we don't have to clean up TODO-RELEASE in the latter case). Also, it does not update LIBVERSION automatically (see https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info...." for details) - I'm not quite sure how this can be automated.
Caveats:
- it does not push the committed result automatically - so far it's left as an additional chance to inspect the changes before pushing them. Also I'm not sure if we have to tweak our gerrit setup to allow for signed tags to go through and how will it interact with auto-rebase.
- it does not replace human decision, it's still your job to adjust version requirements for the libraries you use and properly bump LIBVERSION
- it enforces use of semantic versioning (see my previous email about semver and http://semver.org/ for details)
Questions:
- does it make sense?
- what and, more importantly, how can we automate in addition to that?
The intention is to make release process easy enough so we could make releases more frequently (maybe even have some schedule for it in a long run).
Let me also re-plug the following thread, it has results from OsmoDevCon: https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html "Using repo to make 'regular' releases" on Tue Apr 25 13:40:15 UTC 2017 It seems that we have reached some conclusions which are fading away (at least in my memory), it helps to re-read.
Note the separate topics, on the one hand a general "Osmocom feed" version that provides distribution packages and a common reference for our users, on the other hand the individual version numbers kept in each git tree.
One thing mentioned in that mail is the separation of openbsc.git, which I'm currently working on.
Regarding the patches, I've posted a comment asking about installation of osmo-release.mk, otherwise I haven't taken a detailed look yet.
The topic is non-trivial, and I guess it would be good to have a practical example that includes the entire process: make a change to libosmocore that bumps a version and is required by e.g. libosmo-abis; what exactly are my steps in sequence to achieve that? Does it make sense to have this in a WIP wiki page?
~N
On 12.07.2017 15:11, Neels Hofmeyr wrote:
Let me also re-plug the following thread, it has results from OsmoDevCon: https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html "Using repo to make 'regular' releases" on Tue Apr 25 13:40:15 UTC 2017 It seems that we have reached some conclusions which are fading away (at least in my memory), it helps to re-read.
I think we should put this into wiki.
Regarding the patches, I've posted a comment asking about installation of osmo-release.mk, otherwise I haven't taken a detailed look yet.
Thanks, will fix in next revision.
The topic is non-trivial, and I guess it would be good to have a practical example that includes the entire process: make a change to libosmocore that bumps a version and is required by e.g. libosmo-abis; what exactly are my steps in sequence to achieve that? Does it make sense to have this in a WIP wiki page?
I think it's better to add WIP section to https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
Also, have a look at "When to make a new release" section.
I think it's essential to clearly distinguish between "make a change to library" and "making library release". The former is the usual commit (make sure to update TODO-RELEASE if necessary) and does not require anything special. The latter is when proposed makefile helper comes into play (it batches together several of "make a change to library" commits). Once the result release commit lands in master it you can bump version requirements of projects which depends on it as necessary.
Overall though, I think we should do it other way around: when we need to release one of non-library projects (Osmo*) we should check dependencies and make their releases if necessary before proceeding with the release of the Osmo* project.
-
Max -
Neels Hofmeyr