On Sun, Mar 23, 2008 at 4:07 AM, James Carman <[EMAIL PROTECTED]> wrote: > On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <[EMAIL PROTECTED]> wrote: > > Right. I would not put the to-be-voted-on candidate there, just the > > RCs leading up the the final, all of which have "RC" in their version > > specs. > > From what I understand, we're not supposed to cut release candidates > with "rc" in their version numbers. If you're going to cut a release > candidate, then it's going to be up for a vote. That's why the > version says something like "1.0" so that those exact bits can be > deployed. At least, that's the way it was described to me when doing > proxy. > We have to VOTE on the final bits. It is perfectly fine - and IMO advisable - to make RCs available for review prior to final VOTE. The only hard and fast rule is that we vote on the final bits. Partly for the reason that people's local repos end up with integrity problems, I think it is a bad idea to have final version specs in candidates used for testing and validation. One of the best things about the Maven pom and repo structure is that got us away from "commmons-foo.jar" naming and enforced the discipline that artifact names, built into jar names, are unique and defining. Even just among the development community we should try to stick to that, IMO.
I may be odd man out here, but I see no reason that we should force everyone to stop creating RCs for inspection prior to VOTE. If I have to change the names to SNAPSHOT everywhere to make people happy, I will do that, but as an RM I am not going to produce a sequence of "candidate" jars all with the release name unless something really bad surfaces in the final VOTE. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
