Thanks Tom and Owen for stepping up -- We're using 0.20.2 as effectively 1.0 here, too, so I think a 1.0 branch is a good idea that recognizes that status quo and deal with it, particularly for having a 1.0 that's pre-split and pre-security (big changes).
Couple random thoughts: 1) I agree with marking the old API stable in 1.0, especially considering hive/pig/etc all use it.. what do we do with the new API? Mark it "next-gen"? We have one random job that uses it and I bet that's the same for a lot of people. Leaving it there would be useful as far as not breaking existing code and allowing the frameworks to port over to the new API slowly and not have to maintain 2 branches.. but then that starts to obligate us to fully support the new API on the 1.0 branch. 2) Does this come with a date for 2.0? Will there be a 1.9 or maybe a 2.0-alpha? I think it might be wise to try and deploy an alpha-2.0 branch a few places before making a firm commitment to "this is THE 2.0 API and directory layout". 3) What about append? Based on the amount of work that went into it, I'm assuming it's a very difficult backport.. does this mean 1.0 will never support append? (if it can't, it can't). On Thu, Apr 1, 2010 at 1:11 PM, Chris K Wensel <ch...@wensel.net> wrote: > 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 > >
