Hi all, On a separate thread, a question was raised about 3.x branching and use of feature branches going forward.
We discussed this previously on the "Looking to a Hadoop 3 release" thread that has spanned the years, with Vinod making this proposal (building on ideas from others who also commented in the email thread): http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201604.mbox/browser Pasting here for ease: On an unrelated note, offline I was pitching to a bunch of contributors another idea to deal with rotting trunk post 3.x: *Make 3.x releases off of trunk directly*. What this gains us is that - Trunk is always nearly stable or nearly ready for releases - We no longer have some code lying around in some branch (today’s trunk) that is not releasable because it gets mixed with other undesirable and incompatible changes. - This needs to be coupled with more discipline on individual features - medium to to large features are always worked upon in branches and get merged into trunk (and a nearing release!) when they are ready - All incompatible changes go into some sort of a trunk-incompat branch and stay there till we accumulate enough of those to warrant another major release. Regarding "trunk-incompat", since we're still in the alpha stage for 3.0.0, there's no need for this branch yet. This aspect of Vinod's proposal was still under a bit of discussion; Chris Douglas though we should cut a branch-3 for the first 3.0.0 beta, which aligns with my original thinking. This point doesn't necessarily need to be resolved now though, since again we're still doing alphas. What we should get consensus on is the goal of keeping trunk stable, and achieving that by doing more development on feature branches and being judicious about merges. My sense from the Hadoop 3 email thread (and the more recent one on the async API) is that people are generally in favor of this. We're just about ready to do the first 3.0.0 alpha, so would greatly appreciate everyone's timely response in this matter. Thanks, Andrew
