I have to admit I spent as little time as possible learning how to do maven releases so I don't know the answer to this.
On Wed, Jul 10, 2013 at 11:06 AM, Jake Mannix <jake.man...@gmail.com> wrote: > 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 >
