William A. Rowe, Jr. wrote:
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
forwards...
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>.
I'm not sure this means that the httpd version of the new tarball
stays the same or not if the old tarball fails to get an approval.
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.
That seems like a reasonable policy to distinguish the tarballs.
Let me write up something along these lines for stdcxx and post
it for review.
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,
Understood.
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.
I agree. My concern with changing the version number during
a release is technical rather than procedural.
A library version number must reflect both the backward and forward
(source and binary) compatibility between any two releases of the
library. The rules for assigning the major, minor, and micro (or
patch, when permitted by the system linker) numbers are precisely
specified and correspond to well-defined changes with an impact on
the different types of compatibility (see the rules in effect for
the Rogue Wave C++ Standard library below). There is typically no
allowance in these rules for making version changes that are not
determined by changes and differences between actual code releases.
The version number should also be an indicator of continuity (or
its lack) between releases of the library. Users of the latest
release of a library should be able to decide whether to upgrade
to the new fully compatible release without having to wonder what
they might have missed in the releases in between or whether
a prior release might be sufficient or safer.
Martin
The Rogue Wave C++ Standard Library versioning policy:
The version identifier of a library is typically defined as the
string <major>.<minor>.<micro> with the following semantics:
The major number starts at 1 and is incremented by one for each new
release of the library that is source or binary incompatible with
the previous release. Incrementing the major number resets both
the minor and micro numbers to 0.
The minor number starts at 0 and is incremented by one for each new
release of the library that is forward but not backward compatible
with the previous release. Incrementing the minor number resets
the micro number to 0.
The micro number starts at 0 and is incremented by one for each
new release of the library that contains source code changes that
are backward compatible with the previous release.
A couple of useful references on library and symbol versioning:
http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/
http://sources.redhat.com/autobook/autobook/autobook_91.html
