stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject x.y.z numbering and releases
Date Wed, 18 Jan 2006 20:43:08 GMT
Martin Sebor wrote:
> Justin Erenkrantz wrote:
>> In the future, you should not reuse the version - therefore, this 
>> should really be 4.1.4.  Once, 4.1.3 is posted, it's 'gone' 
>> (regardless of whether it passes or not).  Therefore, a vote should be 
>> with respect to a specific tarball.  If that tarball changes (and a 
>> new version is pushed out), you need to get the minimum 3 +1s on that 
>> specific tarball.
> This is an interesting policy that I think deserves to be discussed
> further. Let me comment on it in a separate thread so as not to
> detract from the vote.

Absolutely not ;-)  Here's your thread for discussion of numbering, going

In the httpd project, the RM (release manager) tags a build, with the final
version number.  If that tarball changes after it leaves their hands, and
is in the hands of testers, it's never modified (much) <sigh>.

Some ASF projects roll a -pre1 or -rc1 tarball.  It's clear to the user
who downloads it that this is almost it, and is being voted on.  If they
don't get cleared, lets say three files change, then they roll -pre2 or -rc2.

Now... in fairness Justin is right; you must vote on the actual tarball you
will ship.  You can't make an incremental change and consider the old votes
still valid.  Heck, maybe those voters even disagree with the suggested change,
or how it was packaged?

But please consider, the candidate must be clearly named.  We have to be able
to determine that Joe, Sandy and Pat all voted +1 on the -same tarball-.  If
we do that with -pre1/-pre2 or -rc1/-rc2, or as httpd does with x.y.z (ditched
or adopted as appropriate), it doesn't so much matter.  It really matters that
we 1) know what people voted on, and 2) know what bugs people are pointing at.
If there are several x.y.z packages all identically named, it's harder to know
that the reporter is pointing at something that's already fixed, newly broken,
or not working the entire cycle.


View raw message