13 Dec
2016
13 Dec
'16
11:21 p.m.
Hi Max,
On Tue, Dec 13, 2016 at 06:29:04PM +0100, Max wrote:
With the migration to gerrit the situation around
version tagging become
even funnier than before. For example right now in libosmocore v0.9.3 does
not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5
and 0.9.6 are committed in reversed order - see output of
git log --tags --show-notes --decorate | grep 'tag:' | head
Thisis indeed odd. The normal procedure should be to push changes via
the gerrit review process, and then after code has ended up in master
push the related tags on those versions.
So the questions are:
- how can I add tag '0.9.3' to commit
abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore
I just did
"git tag -s 0.9.3 abc46af90fde9e9435dee5f4f472aec3f68d3353"
"git push gerrit 0.9.3"
I'm still waiting for this to show up in the public read-only repo on
git.osmocom.org, though.
- how can we prevent the inverted commit situation as
with 0.9.6 and 0.9.5
in future?
The question is how did those tags end up in the repository? Was the
above procedure used, or did somebody push the tags already while
patches were still in review?
- what's the general guidelines for tagging new
versions? Do we go through
gerrit or ask responsible person (who?) to do it manually? Or even auto-tag
commit matching certain criteria?
I think I mentioned it recently somewehre: We should bump the minor
version number each time a new symbol is added to libosmocore, so the
code depending on new symbols can require a certian minimum version.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)