Hi Carsten,I guess one key reason for having multiple mentors is that no two Apache people agree on anything. ;-)
On Jul 22, 2008, at 10:49 PM, Carsten Ziegeler wrote:
Craig L Russell wrote:Yes, that's possible - but I think it's good practice to cut a new release with a new version number each time to reduce possible confusion. Like Roy once said "version numbers are cheap" :)The process doesn't have to fail if you want to respin a build. You can have as many votes as you like for the same release 0.93.
Not necessarily. Right now, there's little difference between 0.93 and 0.94. But if you're planning a 1.0 release and have a failed vote, I'd sure hate to ditch it and make a maintenance release or two before you're out the gate.
I know that in this case it's very unlikely to happen, but imagine that someone already checked out the 0.93 tag from yesterday and distributed it. If we recut a release with the same version numbers there will be two different 0.93 releases out there.
That's why I recommend *not* tagging a release until it's been voted out the door. While the release manager is working on a branch, it's not official.
And besides, what process is it by which some random person checked out a tag and distributed it? It's just as likely that some random person checked out the trunk and distributed it as 1.0.
Which one is the official? So we avoid this by just incrementing the version number.
My input is to suggest that the team create a process that doesn't involve busy work and is transparent to the developers and users. Respinning a release is work; changing the release number is busy work. http://en.wikipedia.org/wiki/Busy_work ;-)
Craig
You are right that the general at incubator list doesn't really want to watch the dev list iterate until there is a release that the dev team is happy with. Then, when dev is happy, you post the vote on general at incubator.Yes, so first vote on this list until "we" are happy :) then second vote on general.The normal practice is for votes to have a subject line that includes [VOTE] in the subject line. If a vote fails, you can call another vote with a note like (second try) in the subject line, if you are keeping the same artifact name. Alternatively, you can add more descriptive tags to the path of the artifacts, e.g. ~cmchen/dist/incubator/sanselan/0.93-try2/ sanselan-0.93-incubating-bin.tar.gz. After a successful vote of 0.93-try2 you can rename the path before copying it (or copy it with the correct name). Of course, it's also ok to respin with a complete new release number, but as you've seen, changing the path names and pom version numbers is pretty painful if all you need to do is to change a few bits and respin the release. Whatever process the team decides on, it should be documented in the svn tree, perhaps in a high level document (at the same level as trunk) called HowToRelease.txt or something similar. The process for release naming and tagging/branching should also be documented.+1 Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
