Re: [Gc] RE: GC version numbering

Ivan Maidanski ivmai at mail.ru
Sun May 20 04:24:24 PDT 2012


Hi Hans,

Sun, 20 May 2012 04:40:24 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> > 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.

Ok.

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

Like this (and name tarball as gc-7.2-rev-b.tar.gz), right? - https://github.com/ivmai/bdwgc/commit/866424d9abcc042d698d5ba32efdfe98b279a083

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

Agree.

Regards,
Ivan

> 
> Hans
> 
> > 
> > Regards.
> > 
> > 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.
> > >
> > > Hans
> > >
> > > > -----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[6]: [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.
> > > > ...
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list