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 is talking about producing a series "not suitable for general consumption", which isn't correct for the latest release 2.0.4. That discussion clearly outlined general (or specific) frustration about breaking compatibility from top level projects.
You are not listing new features for MR and YARN. So it will only be about the four HDFS features Suresh proposed for 2.0.5. As I said earlier my problem with them is that each is big enough to destabilize the code base, and big enough to be targeted for a separate release. The latter relates to the "streamlining" thread on general@. I also think the proposed features will delay stable 2.x beyond the time-frame you projected, because some of them are not implemented yet, and Windows is in unknown to me condition, as integration builds are still not run for it. 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. We can add new features in subsequent release (release). Potentially we can end up in the same place as you proposed but with more certainty along the road. The main reason I am asking for stabilization is to make it available for large installations such as Yahoo sooner. And this will require commitment to compatibility as Bobby mentioned on several occasions. As a rule of thumb compatibility for me means that I can do a rolling upgrade on the cluster. More formal definitions like Karthik's Compatibility page are better. BigTop's integration testing proved to be very productive. Thanks, --Konstantin On Fri, Apr 26, 2013 at 6:06 PM, Arun C Murthy <a...@hortonworks.com> wrote: > Konstantin, > > On Apr 26, 2013, at 4:34 PM, Konstantin Shvachko wrote: > > > Do you think we can call the version you proposed to release > > 2.1.0 or 2.1.0-beta? > > > > The proposed new features imho do not exactly conform with the idea > > of dot-dot release, but definitely qualify for a major number change. > > I am just trying to avoid rather ugly 2.0.4.1 versions, which of course > > also possible. > > I'm agnostic to the schemes. > > During the long discussion we had just 2 months ago, I proposed that 2.1.x > be the beta series initially. > > The feedback and consensus was that it wasn't the right numbering scheme: > http://s.apache.org/1j4 > > thanks, > Arun >