On Jan 11, 2008 8:52 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > On 1/11/08, Matthieu Riou <[EMAIL PROTECTED]> wrote: > > > > Basically you vote on a signed source package which is directly what > gets > > published, with the same signature. If you vote on a RC and then I build > > another release from the same tag to have the final release, anything > can > > happen in the middle (and it has). So the only way to keep the RC thing > > would be to vote twice, once for the RC and another time when the final > > has > > been built from the RC (which would be the real release vote). I find > this > > pretty annoying for several reasons. > > > Short version is, if the RC is an official release you need two votes, > which > I don't find problematic. If the RC is not an official release, you only > need one vote, which I don't find problematic either. Put a file out > there, > mark it 1.1.1-RC, make it an unofficial candidate that people can > experiment > with, just don't call it 1.1.1. >
Agreed. > So the arbitration is between: > > > > * the potential for a big release screwup > > > * sheer luck > > Because we don't control what happens to a file once it gets downloaded, > and > a reasonable developer who has not followed our discussion has no clue > what > it contains. They look at the file name, it's 1.1.1, they think it's > 1.1.1. > But 1.1.1 may still be different. > > Once it gets propagated there's no other mechanism for distinction. > Developers who work in teams put files on shared repositories, you can't > tell who copies the file and what they do with it. Someone who finds the > Apache link can just decide to download it, there's an Apache URL > associated > with the file, but no prior knowledge of this discussion. > > The whole point of have RC2 in the version number is because that's one > convention that is well understood as the file travel in the world, by > people who don't have the knowledge that in the Apache Ode world, 1.1.1 is > sometimes but not always 1.1.1. > We can't do anything about people downloading stuff from random locations and assuming they're what they seem to be just because their name seems right. Anybody can already create a zip that will be named ode-1.1.zip and put it out there with whatever inside. That doesn't make it an official release. My point is: an official release is signed and is distributed by Apache release servers, everything else means nothing. And we can't do much for those who would download from people.apache.org/~mriou and believe this is a final release. It could have been voted down before being published. That being said, my point was more that we can't "upgrade" a RC to a final anymore, like we have done before. Not necessarily that we can't do RCs at all anymore. It's just that when we do RCs, we can't expect them to become final without re-voting and at some point we'll just have to call for a final. Which is what I just did. And if for some reason this final is invalid, then we'll have to cut another final with the same naming and there's nothing we can do about that because we can't get back in time. So the current vote is actually not for a RC but for a final and me using a RC name for the root directory was a mistake. So if it's okay for everybody I'll start a new voting thread using the correct naming. Cheers, Matthieu > > Assaf > > > * less convenience for developers, where you have to be careful where > you > > place each built package (but directories exist for a reason right?) > > > > I'm open to other release processes but we can't work around the > > constraints > > exposed by Roy. > > > > Matthieu > > > > > > >
