Towards 1.0 - Go crazy on trunk/ stableize on branches

[Isabel Drost <is...@apache.org>]

Hi,

it seems one of the major blocking issue for putting a 1.0 release out there is 
backwards compatibility. We already came up with a nice list of facets of Mahout 
that are back-compat related - feel free to review and refine:

https://cwiki.apache.org/MAHOUT/downloads.html

after talking with Simon Willnauer at Apache Con about the way Lucene fixed 
their long release cycles I think we might consider a similar approach:

For each major release give backward compat guarantees as defined above*. As of 
1.0 we set a (rough) time estimate for how long we will provide security-, 
performance-, useability fixes (priority in that order) for each major release. 
Those changes are backported from trunk back to that release's branch. That way 
we can provide frequent releases w/o fear of breaking any compatibility. We 
could even go as far as adding new features marked as experimental if they don't 
break anything but we consider e.g. their API unstable for the next few 
releases.

As for trunk: Taking up the idea brought up earlier and go crazy there. 
Implement all the great new stuff you are thinking about, refactor and improve 
what you think is needed there and cut a next major release "when it's done".

What do you think?

Isabel



* I vaguely remember there being a page with general ideas for defining what 
users could expect on release version changes at the ASF level - I am unable to 
dig that up right now, if it still exists...