are we saying we will de-deprecate the stable APIs in .20, or make the new APIs introduced in .20 stable?
+1 on removing the deprecations on the stable APIs. On Mar 31, 2010, at 2:19 PM, Doug Cutting wrote: > Konstantin Shvachko wrote: >> I would like to propose a straightforward release of 0.21 from current 0.21 >> branch. > > That could be done too. Tom's volunteered to drive a release from trunk in a > few weeks. Owen's volunteered to drive another release from trunk in about > six months. Would you like to volunteer to drive a release from the current > 0.21 branch? > > 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. > > Doug -- Chris K Wensel ch...@concurrentinc.com http://www.concurrentinc.com
