Yes you can do all of this in a branch, which would let things continue to change on HEAD. Otherwise HEAD has to be frozen. I think here there's not enough velocity of change to make freezing HEAD that big of a deal, but yes you could manage the process yourself in a branch if you wanted to.
Tags are changeable in SVN. Nobody is depending on the tag until after the release is finalized, so moving them during the release or reapplying them is no big thing. The release process doesn't update Maven artifacts, even snapshots, so the process does not affect what artifacts end users use. RCs are indeed all labeled "x.y" but are certainly distinguished by date, timestamp. It's not a RC in the sense that it may evolve and change in response to bug fixes over weeks or months -- it's either a valid build or it isn't right now, and is released or not in a few days unless there is a critical build problem. It will only be developers that might ever distinguish several builds. You can use x.y.z for sure and I personally would be happy to see "0.8.0" used instead of "0.8". That is technically more standard Maven convention. I don't think there will be enough change / energy for point releases but it doesn't hurt to allow for the possibility. On Wed, Jul 10, 2013 at 10:11 AM, Stevo Slavić <ssla...@gmail.com> wrote: > This is continuation of my and Grant's discussion on > https://issues.apache.org/jira/browse/MAHOUT-1275 which I believe is better > suited to be continued here on the dev mailing list. > > Apologies for my ignorance, if this discussion took place earlier in the > project lifetime. > > > There is no 0.8 branch here: http://svn.apache.org/viewvc/mahout/branches/ > maven-release-plugin:prepare creates a tag only, which (in svn) although > similar to branch, shouldn't be modifiable, and we need it to be modifiable > if something needs to be changed for final 0.8 release, without > stopping/freezing 0.9 development. > Release instructions basically state that if something is wrong with RC > release, to delete RC release (drop staging repo and delete tag from svn), > rollback version changes on trunk (from 0.9-SNAPSHOT back to 0.8-SNAPSHOT), > make a fix on trunk, and prepare/perform RC release again (same 0.8 release > version). > Current 0.8 RC, IMO is not a proper RC - if we need to make a change to it > and release another RC, there would be no obvious distinction between the > two RCs, especially to Maven builds that Mahout users are likely to be > using, so even after second RC they might still be using/testing with the > old one (cached/resolved in their local repo) as Mahout Maven artifact > coordinates didn't change (same 0.8 version for both RCs). > > In workflow I mentioned (in MAHOUT-1275 comment) - we'd make 0.8.x branch > (with maven-release-plugin branch goal), then from that branch make 0.8.RC1 > release (release:prepare/perform), with 0.8.x branch POMs staying on > 0.8-SNAPSHOT; then if something is found to be wrong with 0.8.RC1, we could > modify the branch (merge the change to 0.9-SNAPSHOT on trunk), and make > another 0.8 RC release, but now of 0.8.RC2 version (different Mahout Maven > artifact coordinates), and so on; when 0.8.RCX is acceptable, passes vote, > we'd make another release or promote 0.8.RCX, to 0.8 or 0.8.FINAL. Final > one would be published on release repository, while all the RCs on staging > repo. Before final release, 0.8.x branch would have 0.8-SNAPSHOT version in > POMs. Branch 0.8.x after final release could have 0.8.1-SNAPSHOT version, > for any critical support changes in future, before 0.9 release. > During whole time of forging 0.8 RC and final releases on their own 0.8.x > branch, 0.9-SNAPSHOT development on trunk can go on. Also, there would be > no rollbacks necessary for RC releases (with exception of cases when it's > really necessary, e.g. when release of some RC is incomplete/breaks because > of network failure or something similar). Also tags stay non-modifiable. > > I noticed at least one Apache project to follow this release workflow (with > staging RCs with different Maven coordinates, and promoting an RC to final > release), namely on Apache HttpComponents project. > > I could understand current release process, if idea is to have all hands > focused on the release while it's being made/tested, and also making it > obvious to community (with absence of branches other than trunk) that there > is no support whatsoever possible/available via minor releases, apart from > changes on trunk and next major release. > > Kind regards, > Stevo Slavić.
