mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Eastman <j...@windwardsolutions.com>
Subject Re: 0.6 and 1.0
Date Mon, 05 Dec 2011 22:07:06 GMT
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>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
>>>
>>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message