Kenney Westerhof wrote:
[snip - much discussion]
Hm. This only describes a major release.
I think that branches should be created off tags, and that a developer
should
do that, not a release plugin.
The above process looks ok for major releases (with reservations), but
we probably don't want to create
a branch for each bugfix release.
Say you're working on maven-2.0.x branch, currently at 2.0.5-SNAPSHOT.
If we follow the above
process, assuming that 'TRUNK' can also mean 'branch', we'd get a
branch for 2.0.5,
which will never change since there are no 2.0.5.x releases. You have
to stop this recursion
somewhere - otherwise you'd get 2.0.5.1.1.1.1 branches.
Personally I like the following process when doing a bugfix release:
1) release:prepare: tag branch 2.0.x as 2.0.5-rc1
2) release:propose: stage 2.0.5-rc1
3) if there are -1's on the proposed release, work on 2.0.x branch
(still at 2.0.5-SNAPHSHOT) and
release 2.0.5-rc2, -rc3 etc, until the release is ACK'd. (so
basically: work on the code, goto step 1,
incrementing the rcX counter).
4) release:accept: tag 2.0.5-rcX (which should be the same as the
branch) as 2.0.5, build tag 2.0.5 and deploy to the live site.
Also update the 2.0.x branch's pom to 2.0.6-SNAPSHOT.
5) For a bugfix release: that's it. For a major release (say 2.1),
also copy the 2.1 tag to a 2.1.x branch.
(the pom's version in trunk will have been updated to 2.2-SNAPSHOT
in step 4).
Comments?
-- Kenney
I like that - automates pretty much what I try to do when releasing :)
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
