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 <[email protected]> > > > > 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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
