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ć.
