libosmocore changes / release process

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Sun Dec 18 16:55:22 UTC 2016


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161218/34c40541/attachment.bin>


More information about the OpenBSC mailing list