Producing new x.0 releases of open source projects is a recurrent problem: too radical a change means the old version gets updated anyway (Python 3) and an incompatible version stops takeup (example, Log4Js dropping support for log4j.properties files),
Similarly, any radical new feature does tend to push out release times longer than you think (Hadoop 2). I think the lessons I'd draw from those and others is: keep an x.0 version as compatible as possible so that everyone can move, and ship fast. You want to be able to retire the 1.x line. And how to ship fast? Keep those features down. For anyone planning anything radical —a branch with a clear plan/schedule to be merged in is probably the best strategy. I actually think the firefox process is the best here, and that it should have been adopted more in Hadoop; ongoing work is going in in branches for some things (erasure coding, IPv6), but there's still pressure to define the release schedule on feature completeness. https://wiki.mozilla.org/Release_Management/Release_Process see also JDD's article on evolution vs revolution in OSS; 15 years old but still valid. At the time, the Jakarta project was the equivalent of the ASF hadoop/big data stack, and indeed, its traces run through the code and the build & test process if you know what to look for http://incubator.apache.org/learn/rules-for-revolutionaries.html -Steve
