Re[4]: GC v7.2e release and version numbering policy

 Hello Hans,

2 issues found:
http://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-7.2e.tar.gz is still not accessible.
http://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-7.4.0 does not have .tar.gz extension

Regards,
Ivan

Friday, 15 Nov 2013, 3:42 UTC from "Boehm, Hans" <[email protected]>:
>Thanks.
>
>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.
>
>Hans
>
>> -----Original Message-----
>> From: Ivan Maidanski [mailto:[email protected]]
>> Sent: Wednesday, November 13, 2013 11:11 PM
>> To: Boehm, Hans
>> Subject: Re[2]: GC v7.2e release and version numbering policy
>> 
>> Hi Hans,
>> 
>> OK, I forwarded it yesterday.
>> 
>> Regards,
>> Ivan
>> 
>> 
>> Tue, 12 Nov 2013, 0:38 UTC from "Boehm, Hans" < [email protected] >:
>> >
>> > 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
>>  [email protected] ?
>> >
>> > Thanks.
>> >
>> > Hans
>> >
>> > From: Ivan Maidanski [mailto:[email protected]]
>> > Sent: Sunday, November 10, 2013 8:31 AM
>> > To: Boehm, Hans
>> > Cc:  [email protected]
>> > 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
>> >
>> > Regards,
>> > Ivan

_______________________________________________
Gc mailing list
Gc-V9/[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/