[Gc] RE: GC v7.2e release and version numbering policy

Boehm, Hans hans.boehm at hp.com
Mon Nov 11 17:01:45 PST 2013

Presumably we still have the option of using nonzero “micro” values for intermediate development releases if we want them labeled?

This would presumably imply some minor changes to GC_version in alloc.s, gc_version.h, etc.

Looks fine to me.


From: Ivan Maidanski [mailto:ivmai at mail.ru]
Sent: Sunday, November 10, 2013 8:31 AM
To: Boehm, Hans
Cc: gc at linux.hpl.hp.com
Subject: GC v7.2e release and version numbering policy

Hi Hans,

1. I've prepared gc-7.2e.tar.gz and libatomic_ops-7.2e.tar.gz (I'll send to you privately in moment) - please do "make check" and put them to gc_source and linux/atomic_ops folder, respectively.

2. I'm going to prepare tarballs for master branches but let's agree on the version numbers policy to avoid confusion with added 'b', 'c',... letters. As someone already mentioned on the ML, major.minor.micro could be a good alternative to major.minor[alpha<alpha>]. I could describe it as:
/* The policy regarding version numbers: development code has odd       */
/* "minor" number (and "micro" part is 0); when development is finished */
/* and a release is prepared, "minor" number is incremented (keeping    */
/* "micro" number still zero), whenever a defect is fixed a new release */
/* is prepared incrementing "micro" number (most stable release has the */
/* biggest "micro" value).                                              */

In other words (similar to libatomic_ops:
* gc-7.2 remains as-is (gc-7.2f, ...)
* gc-7.3alpha3 is finalized to gc-7.4.0
* if a bug will be fixed in gc-7.4.0 then version is changed to gc-7.4.1 when tarball is released (next set of bug fixes goes to gc-7.4.2, so on)
* gc-7.4.0 -> gc-7.5.0 for development (only exists in repository)
* gc-7.5.0 -> gc-7.6.0 on preparing a tarball

The drawback of this scheme is that there is no alpha/beta releases, but OTOH the bigger "micro" value, the more stable release is.

If no objections, I'll prepare gc-7.4.0 and libatomic_ops tarballs.
Thank you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20131112/fd850aa3/attachment-0001.htm

More information about the Gc mailing list