In the absence of further comments, I've pushed this text to a new "Release Versioning" page on the website. I think svnpubsub automatically builds and pushes for us now, but not 100% sure.
Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1 version updates. I'm going to be on vacation until the 15th, but will tackle this when I get back. The bulk updates will also be floowed with a wide-distribution email reminder about how to appropriately set fix versions. Best, Andrew On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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 >>> >> >> >
