Konstantin, On Apr 30, 2013, at 4:28 PM, Konstantin Shvachko wrote:
> Hi Arun, > > I am agnostic about version numbers too, as long as the count goes up. > The discussion you are referring to is somewhat outdated, it was talking > about 2.0.4-beta, which we already passed. It's very relevant and related, we pushed 2.0.4-beta to 2.0.5-beta since we slipped in a 2.0.4-alpha bug-fix release. We could re-visit the same discussion again, but seems hardly worth the time. > If the next release has to be 2.0.5 I would like to make an alternative > proposal, which would include > - stabilization of current 2.0.4 > - making all API changes to allow freezing them post 2.0.5 > And nothing else. I think it's hard to clearly define - 'nothing else'. For e.g. YARN-398/YARN-392. It's a 'feature' but worth putting in right-away since it so low-risk. MAPREDUCE-5108 is a 'feature' but is critical for ensuring a smooth transition from MR1 to MR2 etc. etc. Rather than get tied up in knots, it would be useful to go with API changes as *mandatory* and everything as optional and not hold up the release for them (which is what we have done in hadoop-2.x since forever). IAC, risk should be quantified by people working on individual jiras. Also, it will be useful to actually start testing things as they stand rather than continue to discuss endlessly - would you be willing to help test on of hadoop-2.x? If so, could you please share your plans? I'm sure everyone will appreciate it. From my end (and speaking for rest of my team), we are spending a lot of work running functional and scale tests and also busy ensuring transition from hadoop-1 to hadoop-2 is smooth (e.g. MAPREDUCE-5108). thanks, Arun
