git tagging

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)