[Gc] RE: GC version numbering

Petter Urkedal urkedal at nbi.dk
Mon May 21 13:35:39 PDT 2012


On 2012-05-20, Boehm, Hans wrote:
> > From: Ivan Maidanski [mailto:ivmai at mail.ru]
> > 
> > Hi Hans,
> > 
> > We can switch to the new policy starting from 7.3 by replacing "alpha"
> > component to "micro" one.
> We'd presumably release it as 7.4 instead of 7.3, to avoid confusion between 7.3alpha2 and 7.3.2.  I think that works.
> 
> > 
> > For gc-7.2 (+ the fix) alternatives are:
> > 1. don't alter anything, just do "make dist" and rename tarball to gc-7.2-
> > 201205DD or to gc-7.2.1 or gc-7.2b, or even to gc-7.2.10 (be greater than any
> > alpha released) 2. same as above plus alter version in Readme and configure
> > to 7.2.1 (or 7.2.10 or 7.2-201205DD) 3. same as above plus just add
> > GC_VERSION_MICRO (set to 1 or 10) to gc_version.h.
> > 
> > What do you prefer (for exactly this hot fix)?
> I would probably  just call it revision B in the file name and readme file, and not reflect the change in any of the macros, i.e. something between your option 1 and 2.  I'm not sure I would even change configure or the file name.  The other alternatives seem to add risk of breaking things, as we try to deal with odd inconsistencies between 7.2 versions.  And I'm not sure that programmatic checks for this version difference are important.  If you need the broken functionality, you really just need to upgrade.

If the goal is to avoid editing the configure.ac, then there may be
another solution.  "git describe --tags" will return a revision based on
the closest tag, e.g.

    git describe --match gc\* --tags HEAD	--> gc7_3alpha2-2-g5b25be3
    git describe --match gc\* --tags 6cba390	--> gc7_3alpha2

The AC_INIT arguments cannot be a shell substitutions, but the Autoconf
info page explicitly mentions m4_esyscmd_s for this purpose, so

    AC_INIT([gc],
      m4_bpatsubsts(m4_esyscmd_s([git describe --match gc\* --tags]),
	[_], [.], [\<gc], [], [-\([0-9]+\)-g[0-9a-f]+\>], [.r\1]),
      [gc at linux.hpl.hp.com])

or something similar [1] is valid.  This won't work on a tarball, but
that can be fixed by adding a command to the dist-target which stores
the tag in a distributed file.  The above command should than consider
this file before using "git describe".

I'm not sure whether this is a good idea.  Though the Autotools supports
it, 3rd party tools may expect literals for the AC_INIT arguments.
Note also that it only updates the version when re-running autoreconf.
On the plus side, with [1] it ensures a unique version, as long as tag
names are not re-used.

[1] Actually, it may be better to keep the full -2-g5b25be3 suffix,
since it uniquely determines from which branch the tarball was created.


More information about the Gc mailing list