...not to mention that we are back to executing the tests serially => no more random test failures and longer build times.
________________________________ From: Andrew Musselman <andrew.mussel...@gmail.com> To: dev@mahout.apache.org Sent: Wednesday, July 10, 2013 1:00 PM Subject: Re: Mahout release process That's how the maven release plugin does it in my experience, and yes that's what I get now too. On Wed, Jul 10, 2013 at 10:54 AM, Jake Mannix <jake.man...@gmail.com> wrote: > 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 >
