I made a branch off of 0.8, so presumably any fixes can be made off of that and then we can retag as necessary.
On Jul 14, 2013, at 7:29 AM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Jul 11, 2013, at 12:26 PM, Dmitriy Lyubimov <dlie...@gmail.com> 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? > > I think you can, but the big unknown to me is how Maven handles rollbacks if > something goes wrong. I guess I can always pull the tag/branch and work off > of that. > > >> >> 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. > > I'd say go for it. Of course, my preference would be that time spent on > Mahout right now is focused on testing 0.8, but you are free to do as you > wish. > > >> >> 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 >>> >>> >>> >>> >>> >>> > > -------------------------------------------- > Grant Ingersoll | @gsingers > http://www.lucidworks.com > > > > > -------------------------------------------- Grant Ingersoll | @gsingers http://www.lucidworks.com
