On Mon, Dec 5, 2011 at 1:09 PM, Jeff Eastman <[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 >> > >
