On Sat, May 7, 2011 at 6:36 PM, Ian Holsman <had...@holsman.net> wrote: > > On May 8, 2011, at 9:50 AM, Eric Sammer wrote: > >> do we permit >> backward incompatible changes between 0.22.0 and 0.22.1 or is this >> something we've allowed just for the 203 release? > > good question. > do we allow incompatible (smallish) features to be added to a 20.x release. > hoping that they will eventually be put into trunk at a later stage. > and if we need a process or something around it, or will just act on good > faith that it will occur.
We do allow it, as the 203 release shows. I don't think we need an official process, our existing practice of filing a jira with the appropriate fix version is sufficient. And this seems to be happening already for all changes to future 20x releases. Compatibility is just one reason it's important that features be developed on trunk first. Security and other enhancements were developed on 20 and forward ported to trunk. Almost two years later the forward porting is still not complete - if we released from trunk today, it would not support security. Ditto for append. Some people who work on HBase consider the code in branch-20-append to be more reliable than the code on trunk. This is the primary reason why people are currently on 20.x releases. People are of course free to contribute to Apache on whatever branch they please, but I think as a development community we need to try to make sure a future release off trunk is not a regression against previous releases. This won't happen unless we invest in trunk. I support a release from branch-20-security, I just wanted to see the work go into trunk first. Ie I think the staging matters. (and I agree with Ray wrt the version scheme but that's independent). Fortunately, I don't think we're far off. The vast majority of security work is in trunk (thanks to all those who did the porting), there's probably only 50 to 100 bugs/enhancements in branch-20-security not yet in trunk, and the append code (or rather sync) to support HBase just needs some tests and debugging. I agree with Eric that is is the desire to put improvements into users hands more quickly that drives orgs to produce releases of Hadoop outside Apache. I think the best way to address this is to get solid releases coming off trunk on a regular basis again. Hence the push to close out 22 and work on getting trunk in shape. Also, as a development community, we're at our best when collaborating on trunk. Thanks, Eli
