> My latest proposal, a 1.0 branch based on 0.20, contains two questions: > > 1. Should we make an Apache release that more closely corresponds to what > folks are using in production today (and will be using for a while yet)? > > 2. If we're considering the 0.20 mapreduce and filesystem APIs to be 1.0 > APIs, and the new mapreduce and filesystem APIs to be 2.0 APIs, shouldn't > our release numbering reflect that? Release numbers are fundamentally about > compatibility declarations. We could instead change our compatibility rules > to specifically mention certain release numbers, but that feels the wrong > way around. Since we've not yet made a 0.21 release, we still have an > opportunity to interject a 1.0 release with the semantics folks expect: its > public APIs are stable. > > If there's support for this proposal, then I'd volunteer to drive it. I > won't bother to pursue this unless folks think it is worthwhile, so, if you > like it, please speak up. While a release itself cannot be vetoed and only > requires a simple majority, we'll need to vote which patches would be > applied to a 1.0 branch, and those code-change votes require consensus, so, > vetos there would stop the process. So please also speak up if you strongly > oppose this proposal.
Tom has volunteered to drive a 0.21 release based on trunk. Owen has volunteered to drive the release following that, which will follow Tom's by about six months. Doug, you're volunteering to drive a concurrent 1.0 release based on 0.20? What Owen and Tom have proposed- to ensure API compatibility in releases up to the 1.0 release- has the advantage of stabilizing the mapreduce and FileContext APIs in versions that can actually be deployed. It will also force the dev community to address the issues introduced by the project split, rather than continuing to focus on 0.20 by another name. Among these issues are some pretty basic tasks: implementing a coherent packaging/deployment story, sorting out testing and patch validation across the projects, and stabilizing trunk. Spending the next few months voting and arguing on which patches make it into "new" 0.20 (branched in 2008) instead of addressing these issues is *not* progress. I strongly oppose this. I agree with Konstantin about the viability of 0.21. While the aforementioned, basic issues need to be addressed for both trunk and 0.21- and perhaps duplicating this work on an ancient branch is not well spent- it is already being used. And trunk is not stable: rebasing from trunk now will be hell for committers and contributors. But these decisions need to be made by the release manager. BTW- a vote to adopt the RM role outlined by the httpd project (the long-lost origin of this thread) has not started. If not an httpd-style RM, then what have Tom, Owen, and Doug volunteered to do? While we're at it, perhaps the vote on adopting bylaws needs to be restarted. -C
