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 >
