Martin Sebor wrote:
William A. Rowe, Jr. wrote:
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.
The candidate and number are pitched. We have a mantra,
"version numbers are cheap".
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.
There is typically no
allowance in these rules for making version changes that are not
determined by changes and differences between actual code releases.
Yes, and in fact (unless something went HORRIBLY wrong) the never
released version 1.2.3 enjoys versioning compatibility with 1.2.2
and 1.2.4 per the project's policy. It just simply never existed.
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.
You can argue the converse; treating each and every release as
equally stable doesn't help the user. Stating 'whoops, 1.2.3 just
wasn't up to par, so we've released 1.2.4 following 1.2.2' gives the
user one reassurance; the bad releases don't make it out the door.
Bill
