Thanks for restarting this thread Andrew. I really hope we can get this across to a VOTE so it is clear.
I see a few advantages shipping from trunk: - The lack of need for one additional backport each time. - Feature rot in trunk Instead of creating branch-3, I recommend creating branch-3.x so we can continue doing 3.x releases off branch-3 even after we move trunk to 4.x (I said it :)) On Thu, Jun 9, 2016 at 11:12 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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 >
