On Wed, Jul 10, 2013 at 10:00 AM, Andrew Musselman < andrew.mussel...@gmail.com> wrote:
> That's how the maven release plugin does it in my experience, and yes > that's what I get now too. > Ok, that's fine if it's intended, but it seems to put us in a little bit of a weird state. We tell our users often to build on trunk, so if they're using the current most recent release (0.7), then if they do that now, they go from 0.7 to 0.9-SNAPSHOT. Not the end of the world, but this would be avoided if we were on a release branch, right? Maybe next time, we can do that? > > > 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 > > > -- -jake
