[Gc] Re: GC v7.2e release and version numbering policy
ivmai at mail.ru
Thu Nov 21 14:55:56 PST 2013
2 issues found:
https://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-7.2e.tar.gz is still not accessible.
https://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-7.4.0 does not have .tar.gz extension
Friday, 15 Nov 2013, 3:42 UTC from "Boehm, Hans" <hans.boehm at hp.com>:
>I did make check on an x64 Linux box, and built using Makefile.direct on an ARM box. Everything looked OK. I attempted to put everything in the right places. Libatomic_ops may take a while to show up in the right place.
>> -----Original Message-----
>> From: Ivan Maidanski [mailto:ivmai at mail.ru]
>> Sent: Wednesday, November 13, 2013 11:11 PM
>> To: Boehm, Hans
>> Subject: Re: GC v7.2e release and version numbering policy
>> Hi Hans,
>> OK, I forwarded it yesterday.
>> Tue, 12 Nov 2013, 0:38 UTC from "Boehm, Hans" < hans.boehm at hp.com >:
>> > This is embarrassing. I thought I saw your tar files, and was about
>> to test them, but they seem to have disappeared from my mail box.
>> Overzealous malware
>> > detector? Could you please send them again, with a copy to
>> hansboehm at yahoo.com ?
>> > Thanks.
>> > Hans
>> > 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
>> > 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
>> > Regards,
>> > Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc