Roy T. Fielding wrote: > 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. > Just to be clear, I agree with this and the process I described is not changing the contents of the package which is voted on; just the name is changed. As soon as you make a 1.2.0 available (so the PMC can vote on), people will download it and might think that this is the final 1.2.0 although it hasn't been released yet.
Thinking about the whole stuff a little bit more :) I think, you're right to increase the version number in these cases - it's the only working solution: If the provided package is voted for a release, then everything is fine anyway. If the provided package is not voted for a release, there will never be an official release with this version number and this should avoid the confusion. The only other clean solution would be to make the release candidate only available to PMC members, but imho this is out of question for an open source project. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
