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...
signature.asc
Description: This is a digitally signed message part.
