Re[2]: [Gc] RE: GC version numbering

Ivan Maidanski ivmai at mail.ru
Tue May 22 01:18:21 PDT 2012


Hi Petter and Hans,

Mon, 21 May 2012 22:35:39 +0200 Petter Urkedal <urkedal at nbi.dk>:
> 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 add new tag after changing version in configure.
To me it's not a problem to modify a couple of files bumping the version - the problem is to decide when we should do it and what numbers should use.

Again back to gc7.2, let's finally use version name "gc-7.2b" (seems to be suitable for all parties), right?

Regards,
Ivan

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