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

Ivan Maidanski ivmai at mail.ru
Sun Nov 10 08:31:28 PST 2013

 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/20131110/3d867a06/attachment.htm

More information about the Gc mailing list