Santiago Gala wrote:
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
The problem I have with this approach is that it depends upon RCs which need to be renamed. I think the build should be cut as a test build, voted on as a test build, and either thrown out if it fails to pass, or recategorized as alpha, beta, ga without renaming. Either way, the next published test build should have the next incremental number. No artifact should ever be renamed. It is what it is. This prevents manual modification of the build.
The counter point is that it can become confusing to people that are unaware of our release process. I think that can be rectified easily with a simple pages like:
http://struts.apache.org/downloads.html David
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
