hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@apache.org>
Subject [DISCUSS] A final minor release off branch-2?
Date Sat, 04 Nov 2017 00:07:17 GMT
Hi all,

With 3.0.0 GA around the corner (tx for the push, Andrew!), 2.9.0 RC out (tx Arun / Subru!)
and 2.8.2 (tx Junping!), I think it's high time we have a discussion on how we manage our
developmental bandwidth between 2.x line and 3.x lines.

Once 3.0 GA goes out, we will have two parallel and major release lines. The last time we
were in this situation was back when we did 1.x -> 2.x jump.

The parallel releases implies overhead of decisions, branch-merges and back-ports. Right now
we already do backports for 2.7.5, 2.8.2, 2.9.1, 3.0.1 and potentially a 3.1.0 in a few months
after 3.0.0 GA. And many of these lines - for e.g 2.8, 2.9 - are going to be used for a while
at a bunch of large sites! At the same time, our users won't migrate to 3.0 GA overnight -
so we do have to support two parallel lines.

I propose we start thinking of the fate of branch-2. The idea is to have one final release
that helps our users migrate from 2.x to 3.x. This includes any changes on the older line
to bridge compatibility issues, upgrade issues, layout changes, tooling etc.

We have a few options I think
    -- Make 2.9.x the last minor release off branch-2
    -- Have a maintenance release that bridges 2.9 to 3.x
    -- Continue to make more maintenance releases on 2.8 and 2.9 as necessary
    -- All new features obviously only go into the 3.x line as no features can go into the
maint line.

    -- Create a new 2.10 release which doesn't have any new features, but as a bridging release
    -- Continue to make more maintenance releases on 2.8, 2.9 and 2.10 as necessary
    -- All new features, other than the bridging changes, go into the 3.x line

    -- Continue making branch-2 releases and postpone this discussion for later

I'm leaning towards (A) or to a lesser extent (B). Willing to hear otherwise.

Now, this obviously doesn't mean blocking of any more minor releases on branch-2. Obviously,
any interested committer / PMC can roll up his/her sleeves, create a release plan and release,
but we all need to acknowledge that versions are not cheap and figure out how the community
bandwidth is split overall.

PS: The proposal is obviously not to force everyone to go in one direction but more of a nudging
the community to figure out if we can focus a major part of of our bandwidth on one line.
I had a similar concern when we were doing 2.8 and 3.0 in parallel, but the impending possibility
of spreading too thin is much worse IMO.
PPS: (C) is a bad choice. With 2.8 and 2.9 we are already seeing user adoption splintering
between two lines. With 2.10, 2.11 etc coexisting with 3.0, 3.1 etc, we will revisit the mad
phase years ago when we had 0.20.x, 0.20-security coexisting with 0.21, 0.22 etc.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message