On Saturday October 14 2006 9:30 am, Kenney Westerhof wrote: > 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.
The problem is that this is not ALLOWED. The artifacts that were voted on MUST be the artifacts that are released. You cannot vote on one set of artifacts, then build a whole new set of artifacts for the release. You also cannot go into the artifacts and start changing manifests and such and renaming version numbers/jars/etc.... That was kind of the purpose of the branch. Create the 2.0.5 branch where the "proposals" are made from. The proposals go to a "staging" area (not an official repository like the snapshot or release repositories) with the "real" version number of 2.0.5 where they are voted on. If there are problems, fix it on the branch and rerun propose. Now, the "accept" could do "svn mv branches/2.0.5 tags/2.0.5" or similar to convert the branch to a tag. The branch name could also be something like "2.0.5_prepare_release" or something so we know it's a branch specifically being used to prepare a release and will be "removed" once the release is complete. > > 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 > -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
