Hello Joakim,
I like this discussion, I am a big fan of automating the release
process.
I also have some hands on experience being RM for Ant 1.6 and 1.7.
For Ant 1.7, we are using what you call the staged release process.
When I prepare a build, I have to assume that the vote on the
binaries will be positive and prepare everything with a release
version in mind.
Tagging the release should to my opinion happen between preparing and
staging the release.
To make sure everything is clean, the SVN sandbox could be recreated
based on the tag.
When I did my first build of ANT 1.7.0 last week, someone checked
code in between the time when I created my SVN sandbox and the time
when I created my tag.
In the end, this change was included in the tag but not in my build.
Bad ... See [1] the command used to create the tag
Also, creating a branch for a release is optional. Right now we are
releasing Ant 1.7.0 from the trunk, and we
do not have a ANT_17_BRANCH.
Suggested modifications for your staged release process :
c) 'prepare' release (occurs once)
* Create a branch using provided Branch ID for this release.
* Update poms in branch to provided Release Version ID.
+ * Optionally update documentation in branch to provided
Release Version ID.
* Update poms in trunk to provided Next Development
Version ID.
+ d) tag the release (occurs 1 or more times)
+ e) create a new SVN sandbox using the tag created in d)
- d) stage release (occurs 1 or more times)
+ f) 'stage' release (occurs 1 or more times)
It would be cool if you could persist your ideas concerning the
release process to a document in SVN or to a Wiki page.
Regards,
Antoine
[1]
svn copy https://svn.apache.org/repos/asf/ant/core/trunk \
https://svn.apache.org/repos/asf/ant/core/tags/ANT_170 \
-m "Tagging version 1.7.0 of Ant"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
