Surely we can freeze before then and release around end of January. On Mon, Dec 5, 2011 at 2:07 PM, Jeff Eastman <[email protected]>wrote:
> I don't know, its a pretty big hat. Oh, wait, that would be the shoes > <grin>. But sure, I will dig into this. > > > On 12/5/11 2:34 PM, Jake Mannix wrote: > >> On Mon, Dec 5, 2011 at 1:09 PM, Jeff >> Eastman<jdog@**windwardsolutions.com<[email protected]> >> >wrote: >> >> +dev@ >>> >>> On 0.6, shall we target the end of January for a code freeze and RC? >>> >>> Why wait so long? Can we list the issues that we Really Want to be in >> 0.6, >> and see who owns each one and when they think they can get it done? We >> can >> prioritize them and push out / close / mark as "backlog" those that don't >> look like they'll get attention. >> >> Put on your "Sean-hat" and give us a list of tickets and we can reply >> right >> on this thread on which ones should go in, which should get retagged, etc! >> >> -jake >> >> >> Jeff >>> >>> >>> On 12/5/11 1:20 PM, Isabel Drost wrote: >>> >>> Adding some comments below, though I really think we should be having >>>> that >>>> discussion on dev@ so non-PMC people can add their view as well. >>>> >>>> >>>> On 05.12.2011 Jeff Eastman wrote: >>>> >>>> I don't think Dec is possible, but could we get 0.6 to an RC1 state by >>>>> January >>>>> end? >>>>> >>>>> Sounds good to me. >>>> >>>> >>>> Hadoop is still 0.x >>>> Not for much longer, it seems :) >>>> >>>> >>>> and they are much farther into the production lifecycle than Mahout. >>>> >>>>> What is >>>>> the market force that is driving us for such a release? >>>>> >>>>> Leaving the market and production deployment aside for a bit as I >>>> really >>>> cannot >>>> judge that: >>>> >>>> Our main argument and explanation for 0.x always was keeping our freedom >>>> to >>>> continue breaking compatibility with each release without having to bump >>>> up the >>>> major version at too fast a pace. I think during the past years Mahout >>>> has made >>>> great progress - developers have actually started thinking about >>>> implementing >>>> features such that backwards compatibility is not broken or at least >>>> mark >>>> that >>>> before changing existing implementations too much. >>>> >>>> In addition: >>>> >>>> We've talked in the past about ways to partition Mahout into >>>> >>>>> production-ready and experimental components as a way to set >>>>> expectations about the amount of volatility in our APIs, CLIs, data >>>>> formats, etc. >>>>> >>>>> The results of those discussions result in means that help us break >>>> compatibility in a well defined way that does not surprise users. >>>> >>>> Finally with adopting a release setup similar to the one in Lucene-land >>>> I >>>> think >>>> that even after a 1.x release we would keep our freedom to innovate in a >>>> disruptive way and still be able to have a faster release cycle for >>>> smaller >>>> improvments and bug fixes. >>>> >>>> >>>> Isabel >>>> >>>> >>> >
