On 11/28/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 11/28/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 11/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > Follow up comment on something I missed (and will apply to Rahul's digester > > release candidate as well). Are you planning on respinning the bits with > > the correct version number (1.3.1 instead of 1.3.1-RC1) before the actual > > vote? I prefer to vote on the real bits for an actual release. > > I wasn't planning to as its not the procedure[1] Commons is currently > using. I agree that this is a weakness, since theres potential for > mistakes when the final release is cut. This needs commons to agree a > policy change though. Actually I changed my mind - its only a subversion tag which can be deleted and re-tagged. I'll do this and upload the proposed final artifacts to ~niallp @ apache. Niall > [1] http://jakarta.apache.org/commons/releases/prepare.html
This is a reason why it's bad: http://svn.apache.org/repos/asf/jakarta/commons/proper/discovery/tags/DISCOVERY_0_3/ If you tag the RC's as real releases, then there's a large time period in which a) people can be confused and b) you could lose time and the release never happen. In the above case that didn't happen - the release got passed the voting and just wasn't made, but it highlights why the above would be more dangerous than the current system. So, -1 to a tag of VALIDATOR_1_3_1 at this stage, and -1 to putting it in ~niallp/validator-1.3.1/, it should be in ~niallp/validator-1.3.1-rc2/ (or whatever we're on). However +1 to the file structure you have - we shouldn't be pissing around with 1.3-rc1 in the project.xml etc, we should be just trying for the real release and then copying those exact files off to the various places. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
