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. 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. 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 > > >
