Grant, so we have released then and can commit 0.9 issues to trunk now? or we are still frozen and waiting for final release steps? or release candidates?
because it is my understanding that after we have build 0.9 artifacts, we cannot build them again -- so we must have built final 0.9 then. If for some reason we are not happy with 0.9 artifacts we kind of have to build something like 0.9.1 but not 0.9 again... anyway i just want to know when it is ok to start pushing 0.9 things to master. Thank you, sir. -d On Thu, Jul 11, 2013 at 7:31 AM, Grant Ingersoll <gsing...@apache.org>wrote: > > On Jul 10, 2013, at 5:05 PM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > > > i thought maven release:prepare changes from 0.8-SNAPSHOT to 0.8 (and > > eliminates snapshot dependencies). and release:perform goes from 0.8 to > > 0.9-SNAPSHOT. I.e. it guarantees that by the time you have 0.9-SNAPSHOT > > set, you also have a released 0.8 build. > > Correct. The release artifacts are 0.8, no SNAPSHOT, trunk is 0.9-SNAPSHOT > > > > > but for some reason it is not what is happening now on trunk. > > > > > > On Wed, Jul 10, 2013 at 10: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 > >> > > -------------------------------------------- > Grant Ingersoll | @gsingers > http://www.lucidworks.com > > > > > >
