> 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. >
it looks good on my part. I found however that a bug was (re-?) introduced into UpperTriangular matrix( breaks row count property in certain form of constructor) which however did not seem to affect any of existing solvers. this is fixed as a part of M-1281 I however don't have access to a decently sized cluster anymore to use for my personal experiments so unlike Sebastian I cannot verify at scale. -d > > > > > > 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 > > > > > >
