On Wednesday 04 May 2016 14:12:05 Richard W.M. Jones wrote:
On Wed, May 04, 2016 at 02:17:00PM +0200, Pino Toscano wrote:
> On Tuesday 03 May 2016 21:27:47 Richard W.M. Jones wrote:
> >
> > For historical reasons that don't really matter now, we currently
> > tag all releases with just the version number, eg:
> >
> > commit 6b48977cb7100e4f214b189052d4f0bf61523d11 (HEAD -> master, tag:
1.33.26, origin/master, origin/HEAD)
> > Author: Richard W.M. Jones <rjones(a)redhat.com>
> > Date: Tue May 3 14:49:59 2016 +0100
> >
> > Version 1.33.26.
> >
> > Of course this isn't the way that git versions are normally tagged.
> > The normal convention is to use "v<VERSION>" (eg.
"v1.33.26").
> >
> > I propose that I start tagging new releases this way (see the patch
> > below). This shouldn't be controversial.
> >
> > The question is should I tag new releases with the "old style" tags?
> > I'd prefer not to. Should I go back and add "v<VERSION>"
tags to all
> > the old releases? Again, I'd prefer not to, but could do that if
> > anyone thinks it's necessary.
>
> I've seen both ways used IMHO equally, so I don't have a strong
> preference.
>
> Just wondering whether the right moment for changing tag naming would
> be when tagging the .0 of a new series.
Perhaps, but I'd say an argument against doing it for a .0 release
would be that it lets us test that our CI & build tools work now
during the development phase. (Unless you mean .0 of the next
development release, which punts the whole thing far into the future.)
My point was that each series had a coherent naming for all its tags.
Be it because the switch is done after branch cutting, or that
older/newer releases are tagged in the other way, it's the same for me.
--
Pino Toscano