hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject [DISCUSS] Increased use of feature branches
Date Fri, 10 Jun 2016 06:12:50 GMT
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):


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

We're just about ready to do the first 3.0.0 alpha, so would greatly
appreciate everyone's timely response in this matter.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message