I've written up the proposal from my initial reply in a GDoc. I found one bug in the rules when working through my example again, and also incorporated Akira's correction. Thanks all for the discussion so far!
https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit Ping me if you'd like edit/comment privs, or send comments to this thread. I'm eager to close on this so we can keeping pushing on the 2.8.0 and 3.0.0-alpha1 releases. I'd like to post this content somewhere official early next week, so if you have additional feedback, please keep it coming. Best, Andrew On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com> wrote: > Inline. > > >> >>> BTW, I never see we have a clear definition for alpha release. It is >>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.) >>> but sometimes means unstable in production quality (2.7.0). I think we >>> should clearly define it with major consensus so user won't >>> misunderstanding the risky here. >>> >> >> These are the definitions of "alpha" and "beta" used leading up to the >> 2.2 GA release, so it's not something new. These are also the normal >> industry definitions. Alpha means no API compatibility guarantees, early >> software. Beta means API compatible, but still some bugs. >> >> If anything, we never defined the terms "alpha" and "beta" for 2.x >> releases post-2.2 GA. The thinking was that everything after would be >> compatible and thus (at the least) never alpha. I think this is why the >> website talks about the 2.7.x line as "stable" or "unstable" instead, but >> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1, >> we could have just called 2.7.0 "beta". >> >> I think this would be good to have in our compat guidelines or somewhere. >> Happy to work with Karthik/Vinod/others on this. >> > > I am not sure if we formally defined the terms "alpha" and "beta" for > Hadoop 2, but my understanding of them agrees with the general definitions > on the web. > > Alpha: > > - Early version for testing - integration with downstream, deployment > etc. > - Not feature complete > - No compatibility guarantees yet > > Beta: > > - Feature complete > - API compatibility guaranteed > - Need clear definition for other kinds of compatibility (wire, > client-dependencies, server-dependencies etc.) > - Not ready for production deployments > > GA > > - Ready for production > - All the usual compatibility guarantees apply. > > If there is general agreement, I can work towards getting this into our > documentation. > > >> >>> Also, if we treat our 3.0.0-alpha release work seriously, we should also >>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there >>> could be no room for 3.0 incompatible feature/bits soon. >>> >>> While we're still in alpha for 3.0.0, there's no need for a separate >> 4.0.0 version since there's no guarantee of API compatibility. I plan to >> cut a branch-3 for the beta period, at which point we'll upgrade trunk to >> 4.0.0-alpha1. This is something we discussed on another mailing list thread. >> > > Branching at beta time seems reasonable. > > Overall, are there any incompatible changes on trunk that we wouldn't be > comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping > those bits ever? > > >> >> Best, >> Andrew >> > >
