Libguestfs - May 2016 - Re: Proposal to start tagging releases in git with v<VERSION>

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@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.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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@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

On Wed, May 04, 2016 at 04:00:24PM +0200, Pino Toscano
wrote:
> 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@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.
I pushed the patch.  I will go and add the v-tags for all releases in
the 1.33 branch (but not any earlier branches), which I think should
satisfy this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v