3:27 p.m.
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.
Rich.
From fe9493a5a0dd34d5f3ffc1f5dbe76a8724011225 Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" <rjones(a)redhat.com>
Date: Tue, 3 May 2016 21:25:54 +0100
Subject: [PATCH] Tag versions with "v<VERSION>" instead of just the
version
number.
This is the normal convention used for tagging git releases.
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index f4520c8..cef9129 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -524,7 +524,7 @@ maintainer-commit:
# Tag HEAD with current version (only for maintainer).
maintainer-tag:
- git tag -a $(VERSION) -m "Version $(VERSION) ($(BRANCH_TYPE))" -f
+ git tag -a "v$(VERSION)" -m "Version $(VERSION) ($(BRANCH_TYPE))"
-f
# Maintainer only: check EXTRA_DIST rule is complete.
# (Note you must have done 'make dist')
--
2.7.4
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
7:17 a.m.
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.
--
Pino Toscano
8:12 a.m.
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.)
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
9 a.m.
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
11:51 a.m.
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(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.
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
3048
days inactive
3049
days old
4 comments
2 participants
participants (2)
-
Pino Toscano -
Richard W.M. Jones