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
