[Gc] GC version numbering
ivmai at mail.ru
Sat May 19 06:51:07 PDT 2012
We can switch to the new policy starting from 7.3 by replacing "alpha" component to "micro" one.
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)?
Wed, 16 May 2012 23:33:28 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> Our current version numbering unfortunately doesn't really handle this case. Historically we've just produced another stable version with the fix eventually, which isn't a good solution here. It makes sense to switch to a version numbering scheme that handles small bug fixes like this better. Unfortunately the obvious alternatives seem to cause the GC_version variable to behave strangely, so that "newer" no longer corresponds to ">". Maybe we just need to introduce a revision number which isn't reflected in GC_version for now and switch to a different scheme when we would otherwise bump the version to 7.4.
> > -----Original Message-----
> > From: Ivan Maidanski [mailto:ivmai at mail.ru]
> > Sent: Wednesday, May 16, 2012 2:39 AM
> > To: Boehm, Hans
> > Cc: Jan Wielemaker; gc at linux.hpl.hp.com
> > Subject: Re: [PATCH] Re: Found? Re: [Gc] Assertion failure in
> > GC_malloc_uncollectabl
> > Hi Hans,
> > I've committed the fix (exactly the change as you said) to GC
> > v7.3alpha3. (I think later (although I'm not sure right now) to replace
> > GC_generic_malloc call with GC_generic_malloc_internal one in
> > GC_malloc_uncollectable to avoid locking twice.)
> > But v7.2 should also be fixed - please consult me with the versioning:
> > it should be something like v7.2.1 but not some alpha.
> > Regards.
> > ...
More information about the Gc