On Jan 17, 2007, at 5:47 AM, Carsten Ziegeler wrote:
Raphael Wegmueller wrote:
the usage of the 3rd version digit as a sort of rc counter sounds
rather confusing to me, too...
how about always suffixing release candidates that are voted on with
-rcN, and after acceptance releasing the same binaries again, this
time without suffixes? their md5 checksums would be identical, so
there should be no confusion as to which rc it is, and the release
would have the proper version.
This is the way how other projects at Apache perform the release
process
(preparing everything as version x.y(.z)-rcN, building the dist with
this version information and also creating this tag/branch in svn). If
the vote is successful, the suffix is just removed.
Release votes are on the final source package as built and signed by
one of the trusted PMC members. Voting on anything other than that
is a waste of time, as the vote would have to be repeated for the
final package testing. The votes are an indication of the number of
people who have downloaded the source package, verified the signature,
unpacked it, built it from the source, and then run whatever tests
that individual feels are sufficient to earn that person's +1.
No source package can be released without three binding +1s from
the PMC on *that* package.
Version numbers are cheap. It costs nothing to increment the third
(a.k.a., patch-level) number every time a change is made to the posted
packages. It costs a great deal to repeat all of the source-based
testing and votes just because someone has to go back and remove a
bunch of worthless rcN suffixes.
Speaking as the former chairman, any ASF project that is voting on
packages and then changing them before release is violating Apache
guidelines on how to prepare a release. They should learn how to do
it right. And, yes, I am aware that some Jakarta projects have
never produced a valid release.
....Roy
