16 Dec
2016
16 Dec
'16
1:10 p.m.
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_releas…
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
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
16 Dec
16 Dec
1:18 p.m.
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(a)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
3:58 p.m.
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(a)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
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
4:04 p.m.
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
--
Max Suraev <msuraev(a)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
11:20 p.m.
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
18 Dec
18 Dec
3:53 p.m.
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
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
4:26 p.m.
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.
--
Max Suraev <msuraev(a)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 Directors: Holger Freyther, Harald Welte
4:55 p.m.
On Sun, Dec 18, 2016 at 05:26:09PM +0100, Max wrote:
Hi.
Some comments are inline.
18.12.2016 16:53, Neels Hofmeyr пишет:
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'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. 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
3110
days inactive
3112
days old
7 comments
3 participants
participants (3)
-
Max -
Neels Hofmeyr -
Sylvain Munaut