Santiago Gala wrote: > > There was a long discussion on this in [EMAIL PROTECTED], iirc. > > The principles are: > - one can only vote on a concrete binary artifact, together with a > source control revision number. Voting first and releasing later raises > the possibility of having a release on "intention", which is completely > broken. > - re-cutting a release is very confusing for people trusting release > names, specially on the face of SHA1/MD5 signatures and automated build > tools. I got very angry when I found I had problems with several > different Borland DLLs, all with the same version, but with different > size and content. It was crazy to debug and re-deploy. > > On those principles, the procedure is something like: > - one cuts RCn releases, and tests them. Bugs are reported, etc. People > can even use those "snamshots" for dependencies, at least temporarily, > as they are stable. > - once there is a raising consensus that the Release Candidate is > "good", a vote is called. People has further time to deploy it and test > compatibility before they vote. > - the *exact* RC voted is renamed as release, or a new RC is generated. > - rinse and repeat > > So, I'd support both policies. As our projects keep maturing, having > stable and trustable releases is a must. > > Carsten, am I missing something, or got some idea wrong? > If there is consensus that a specific RC (or the current svn) should be the final release, the release package has to be prepared and then voted on. It is not good practice to vote on an RC, change the contents (for example by just removing the RC postfix on the version umber) and then push this out as the final release. The vote has to be done on the "real thing".
Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
