Craig L Russell wrote:
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.
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" :)
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. Which one is the official?
So we avoid this by just incrementing the version number.
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]
