When I now change pretty much anything in libosmocore that I want to use in e.g. openbsc.git, I would like to bump the minor revision and reference that in other projects' configure.ac.
The effort is ok if it entails only tagging a revision and using that elsewhere. However, this has come down to a lengthy process:
" cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE) update debian/changelog using "gbp dch" command " https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release...
So, pretty much every commit in libosmocore will be followed by another commit that is adjusting the changelog...? :/
Should we adjust the changelog along with pretty much any change used outside of libosmocore? :/ (probably not, because reverting anything is made cumbersome)
Should we rather, like, make a libosmocore release only once a week and somehow track wich other projects need a bump to the required libosmocore version?
I think most projects out there make a release tag only every now and then. We could limit to noting the required libosmocore change-id in other projects' commit logs until the next (minor) release is made...?
Can we add a fourth level of version that doesn't require a changelog/debian release? So for every small change I make I would tag 0.9.6.1, 0.9.6.2, etc., and at some point we make 0.9.7 along with a changelog adjustment?
Thoughts?
~N
Hi.
I think making new release from libosmocore master just because something in OpenBSC (or other reverse dependency) master requires new functionality is just a waste of efforts. Instead I suggest to make it simple:
- recent master version always requires recent master version of all the libraries (libosmo*): it might still work with some earlier version but that just means you're lucky
- release version shall require appropriate release version of library
This way we only have to make release for libosmo* when we're about to make release of OpenBSC, OsmoBTS etc. which does not happen that often.
Sounds good, but how do we keep track which libosmocore version a dependent project requires? When I add foo to libosmocore and use foo in openbsc, I will definitely forget which needs which by the time a release is made...
Write down required bumps in TODO-RELEASE of libosmocore?
~N
On Fri, Dec 16, 2016 at 02:18:35PM +0100, Max wrote:
Hi.
I think making new release from libosmocore master just because something in OpenBSC (or other reverse dependency) master requires new functionality is just a waste of efforts. Instead I suggest to make it simple:
- recent master version always requires recent master version of all the
libraries (libosmo*): it might still work with some earlier version but that just means you're lucky
- release version shall require appropriate release version of library
This way we only have to make release for libosmo* when we're about to make release of OpenBSC, OsmoBTS etc. which does not happen that often.
-- Max Suraev msuraev@sysmocom.de http://www.sysmocom.de/ =======================================================================
- sysmocom - systems for mobile communications GmbH
- Alt-Moabit 93
- 10559 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Director: Harald Welte
I'd say write in both:
- TODO-RELEASE in OpenBSC/OsmoBTS/whatever: "bump libosmo-X with change Y before release"
- TODO-RELEASE in libosmo-*: "change Y: blah-blah"
Unless someone can come with easier or more automatable scheme.
On 16.12.2016 16:58, Neels Hofmeyr wrote:
Sounds good, but how do we keep track which libosmocore version a dependent project requires? When I add foo to libosmocore and use foo in openbsc, I will definitely forget which needs which by the time a release is made...
Write down required bumps in TODO-RELEASE of libosmocore?
~N
How about when you make a release N of libosmocore, right after the release and tag you already upgrade the version internally to N+1
Then when you use a new function in the lib and depend on it in OpenBSC, you can directly add dependency to libosmocore version N+1 in the OpenBSC automake stuff.
Cheers,
Sylvain
On Sat, Dec 17, 2016 at 12:20:11AM +0100, Sylvain Munaut wrote:
How about when you make a release N of libosmocore, right after the release and tag you already upgrade the version internally to N+1
Then when you use a new function in the lib and depend on it in OpenBSC, you can directly add dependency to libosmocore version N+1 in the OpenBSC automake stuff.
I'd like to +1 this, but for one implementation detail: at the moment e.g. an installation of libosmocore finds the most recent signed tag in git and bases the installed version number on that. So either we need a "moving tag" that continuously follows master (I think not), or we change the way that ./configure figures out what the current version number to be installed is.
It's nice to have an automatic lookup, so that the git tag magically gives the right version number, but we do also have manual work to do in the debian files for a release anyway. So I guess it would be handy to note the version manually instead of using git tags (i.e. keep the .version file in git), then we could go with this scheme. We could have some sort of validation step in the release process to ensure a tag is also set on a revision with matching content in .version.
I think it's a really good idea, what do you others think?
~N
Hi.
Some comments are inline.
18.12.2016 16:53, Neels Hofmeyr пишет:
I'd like to +1 this, but for one implementation detail: at the moment e.g. an installation of libosmocore finds the most recent signed tag in git and bases the installed version number on that. So either we need a "moving tag" that continuously follows master (I think not), or we change the way that ./configure figures out what the current version number to be installed is.
Could describe this in more details? What exactly do you mean by "installation finds"? When I install new libosmocore locally via dpkg the version number is defined by the latest entry in debian/changelog.
It's nice to have an automatic lookup, so that the git tag magically gives the right version number, but we do also have manual work to do in the debian files for a release anyway. So I guess it would be handy to note the version manually instead of using git tags (i.e. keep the .version file in git), then we could go with this scheme. We could have some sort of validation step in the release process to ensure a tag is also set on a revision with matching content in .version.
I think it's a really good idea, what do you others think?
I think it's extremely bad idea to keep auto-generated data under version control and than try to deal with version controlled vs autogenerated mess.
Besides I don't really understand the problem you're trying to solve to begin with, but I'm pretty sure that storing generated version data under git is not the best way to go.
On Sun, Dec 18, 2016 at 05:26:09PM +0100, Max wrote:
Hi.
Some comments are inline.
18.12.2016 16:53, Neels Hofmeyr пишет:
I'd like to +1 this, but for one implementation detail: at the moment e.g. an installation of libosmocore finds the most recent signed tag in git and bases the installed version number on that. So either we need a "moving tag" that continuously follows master (I think not), or we change the way that ./configure figures out what the current version number to be installed is.
Could describe this in more details? What exactly do you mean by "installation finds"? When I install new libosmocore locally via dpkg the version number is defined by the latest entry in debian/changelog.
The local file '.version' is created by the 'make' step (if it doesn't exist yet), and it is created by git-version-gen, which looks up a signed tag in git. When I do 'make install', this is what determines the version number.
Now, I'm entirely not sure how this goes in debian. Does the debian package version also come from this .version file, or by an entirely separate process? In that case a 'make install' could possibly install one version, and a debian package install could install another, both based on the exact same source tree... :/
I think it's extremely bad idea to keep auto-generated data under version control and than try to deal with version controlled vs autogenerated mess.
My idea was to not auto-generate .version anymore, so we can manually N+1 the revision without having to set a revision tag.
Besides I don't really understand the problem you're trying to solve to begin with
Sylvain's idea is to manually N+1 after a release.
As I said, to get the version number to change during 'make install', I so far need a git tag; and I don't want to maintain a git tag that follows every single 'master' commit. Hence manual .version file.
(Of course I could manually overwrite my local .version file, but the point is to find a general way to N+1 the version directly after a release.)
Does my argument make more sense now?
A problem I still see is that the .version file also contains a git hash that is auto-generated. But I notice that this is updated only when I manually rm the '.version' file, so it is usually out of date for my local builds.
A bit of detail should be sorted out there, but you get my general direction.
~N
-
Max -
Neels Hofmeyr -
Sylvain Munaut