El mar, 06-03-2007 a las 13:44 -0500, David H. DeWolf escribió: (...) > > > > I don't see the harm in re-rolling the distribution. We did it a > couple > > of times for 1.1.0. > > That's a PMC decision and right now it looks like the PMC prefers to > not > recut releases. I'm sure that fairly soon the PMC will come out with > a > defined release process, for now, I'm just trying to follow the > spirit > of the law that doesn't exist yet. > > Carsten, can you help explain the reasoning behind this? While I > agree > with it, I'm not sure I totally understand the reasons why it makes > sense :). On the surface it sounds scary to people, but in practice, > after accepting it, I've liked it. Can you help explain why?
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? Regards Santiago
