Looking at the issues I just posted and the impact of the upcoming
holidays, when is realistic for code freeze? New Years Day?
On 12/5/11 3:29 PM, Ted Dunning wrote:
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
