So quick question: is an intentional side-effect of the current release process that when we build on trunk now, we build artifacts named e.g. mahout-examples-0.9-SNAPSHOT-job.jar ?
On Wed, Jul 10, 2013 at 2:33 AM, Sean Owen <sro...@gmail.com> wrote: > 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ć. > -- -jake
