hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun Suresh <asur...@apache.org>
Subject Re: [DISCUSS] A final minor release off branch-2?
Date Sun, 05 Nov 2017 21:46:28 GMT
Thanks for starting this discussion VInod.

I agree (C) is a bad idea.
I would prefer (A) given that ATM, branch-2 is still very close to
branch-2.9 - and it is a good time to make a collective decision to lock
down commits to branch-2.

I think we should also clearly define what the 'bridging' release should be.
I assume it means the following:
* Any 2.x user wanting to move to 3.x must first upgrade to the bridging
release first and then upgrade to the 3.x release.
* With regard to state store upgrades (at least NM state stores) the
bridging state stores should be aware of all new 3.x keys so the implicit
assumption would be that a user can only rollback from the 3.x release to
the bridging release and not to the old 2.x release.
* Use the opportunity to clean up deprecated API ?
* Do we even want to consider a separate bridging release for 2.7, 2.8 an
2.9 lines ?

Cheers
-Arun

On Fri, Nov 3, 2017 at 5:07 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org>
wrote:

> 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
>  (A)
>     -- 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.
>
>  (B)
>     -- 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
>
>  (C)
>     -- 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.
>
> Thanks
> +Vinod
> 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.

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