i am sorry i meant 0.8 artifacts of course, not 0.9
On Thu, Jul 11, 2013 at 9:26 AM, Dmitriy Lyubimov <[email protected]> wrote: > 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 <[email protected]>wrote: > >> >> On Jul 10, 2013, at 5:05 PM, Dmitriy Lyubimov <[email protected]> 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 <[email protected]> >> wrote: >> > >> >> On Wed, Jul 10, 2013 at 10:00 AM, Andrew Musselman < >> >> [email protected]> 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 <[email protected]> >> >>> 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 <[email protected]> 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ć <[email protected]> >> >>>> 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 >> >> >> >> >> >> >
