+dev@

I agree we are maturing as a project and that it is reasonable for us to offer more consistency between releases than 0.x might imply. I'd like to learn more about how Lucene is approaching this challenge. Do you have a link that describes this approach?

I think it would be a useful exercise for us to partition our functionality so that we can communicate our own assessment of the maturity of our various implementations. I will create a wiki page for this and attempt to enumerate our functionality so that this process can begin. It will be helpful to me personally in my new role to develop this overview, and so I will volunteer to start this process.

On 0.6, shall we target the end of January for a code freeze and RC?

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

Reply via email to