hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: Looking to a Hadoop 3 release
Date Sun, 24 Apr 2016 01:53:32 GMT
If we're not starting branch-3/trunk, what would distinguish it from
trunk/trunk-incompat? Is it the same mechanism with different labels?

That may be a reasonable strategy when we create branch-3, as a
release branch for beta. Releasing 3.x from trunk will help us figure
out which incompatibilities can be called out in an upgrade guide
(e.g., "new feature X is incompatible with uncommon configuration Y")
and which require code changes (e.g., "data loss upgrading a cluster
with feature X"). Given how long trunk has been unreleased, we need
more data from deployments to triage. How to manage transitions
between major versions will always be case-by-case; consensus on how
we'll address generic incompatible changes is not saving any work.

Once created, removing functionality from branch-3 (leaving it in
trunk) _because_ nobody volunteers cycles to address urgent
compatibility issues is fair. It's also more workable than asking that
features be committed to a branch that we have no plan to release,
even as alpha. -C

On Fri, Apr 22, 2016 at 6:50 PM, Vinod Kumar Vavilapalli
<vinodkv@apache.org> wrote:
> Tx for your replies, Andrew.
>>> For exit criteria, how about we time box it? My plan was to do monthly
>> alphas through the summer, leading up to beta in late August / early Sep.
>> At that point we freeze and stabilize for GA in Nov/Dec.
> Time-boxing is a reasonable exit-criterion.
>> In this case, does trunk-incompat essentially become the new trunk? Or are
>> we treating trunk-incompat as a feature branch, which periodically merges
>> changes from trunk?
> It’s the later. Essentially
>  - trunk-incompat = trunk + only incompatible changes, periodically kept up-to-date to
>  - trunk is always ready to ship
>  - and no compatible code gets left behind
> The reason for my proposal like this is to address the tension between “there is lot
of compatible code in trunk that we are not shipping” and “don’t ship trunk, it has
incompatibilities”. With this, we will not have (compatible) code not getting shipped to
> Obviously, we can forget about all of my proposal completely if everyone puts in all
compatible code into branch-2 / branch-3 or whatever the main releasable branch is. This didn’t
work in practice, have seen this not happening prominently during 0.21, and now 3.x.
> There is another related issue - "my feature is nearly ready, so I’ll just merge it
into trunk as we don’t release that anyways, but not the current releasable branch - I’m
lazy to fix the last few stability related issues”. With this, we will (should) get more
disciplined, take feature stability on a branch seriously and merge a feature branch only
when it is truly ready!
>> For 3.x, my strawman was to release off trunk for the alphas, then branch a
>> branch-3 for the beta and onwards.
> Repeating above, I’m proposing continuing to make GA 3.x releases also off of trunk!
This way only incompatible changes don’t get shipped to users - by design! Eventually, trunk-incompat
will be latest 3.x GA + enough incompatible code to warrant a 4.x, 5.x etc.
> +Vinod

View raw message