On Sat, 28 Oct 2006, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > This procedure for releases opens for me a number of questions : > > - does it not force the project to actually hold two votes, one to > choose a date to build a release candidate, the second to decide > whether this release candidate is valid ?
No, only the second is necessary. Anybody could say "look this is what I'd like to release" and call for a vote any time. I like our more organized release plan vote better, though. > - should the release manager tag the code in any case before > building ? Now there is a danger that you create a tag ANT_170 but > then you get a negative vote, this is not 1.7.0 any more. I had this problem with AntUnit 1.0Beta2 - there I went ahead and removed the old tag and created a new one. Not sure whether this was the best approach. > - since we will be releasing both to the maven directory tree and > using our usual distribution system, does the release manager also > need to upload the java-repository directory tree, maybe as a zip > file ? I don't count publishing to the java-repository as a release, but probably you are right, we'd need to verify them as well. > - this procedure makes lose the time of the vote on the binary > artifacts, where the release could actually already be made > available You wouldn't push them into the dist directory until the vote has passed. > - there is no clear calendar. I find it better if a project commits > itself to some clear milestones Nothing prevents us from doing this in addition to making sure our release artifacts have been voted on "correctly". > If you say this system of creating a release candidate, uploading it > to ~release_manager/betadistribution, then voting on accepting this > as version xyz is ASF procedure, then I will have to live with > it. AFAIU it is. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
