You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hbase.apache.org by Sean Busbey <bu...@apache.org> on 2020/02/15 01:57:16 UTC

[DISCUSS] HBase 3 release plans

Hi folks!

Consider this the start of my release manager duties for HBase 3.0.0.

HBase 2.0 started alpha releases in Jun 2017 and went GA in April
2018. I'd like to start alpha releases for HBase 3.0 next week and aim
for a GA in December or January.

As RM, I consider the alpha releases a chance for folks to shake
things out and for us to decide as a community what makes it in or not
for the release line. Once things start being labeled beta, I would
like things to be feature frozen. My current goal is to set beta in
May or June.

I would like HBase 3.0 to be the start of us getting into practice on
tighter iteration cycles for major versions. 2.5 years is too long. We
should try to look at our version numbers as akin to Linux kernel
version numbers. Something useful to those interested in the internals
of the project but not something where most downstream users have to
dread major bumps. To that end I would like HBase 3.0 to be rolling
upgradable from HBase 2.y at GA. Ultimately, I would like to update
our reference guide's section on compatibility to state that future
major releases will similarly be rolling upgradable from some minor
release of the prior major release line.

Given my desire to make major upgrades less of a world changing event
for our downstream folks, I also don't have any new features that I
feel strongly need to make it into HBase 3.0. I'll do a review of
what's currently there so we can motivate folks, but I won't do that
until we're ready to declare beta since that will be when I'll have a
better idea of what's actually ready to ship.

With the major version change I'd like us to shed some maintenance
burden in the project. For each of these, doing that will require
getting a branch-2 release out that can successfully opt-in to the
HBase 3 requirement and run on the current HBase 2 requirement. That
way folks can do a rolling restart within HBase 2 to make the change,
then do a rolling upgrade to HBase 3.

= Hadoop 3 only

The Hadoop community's focus increasingly is on Hadoop 3.y releases. A
substantial amount of our dependency handling is tied to trying to
span both Hadoop 2 and Hadoop 3. I would like us to drop Hadoop 2
entirely. I think branch-2 is currently in a place where running on
Hadoop 3 is reasonable.

= JDK11+

We've been bending over backwards on jdk versions for a while. Maven
build sets up for multiple jdk builds are a PITA and our existing
build is already too complicated. I'd like us to get branch-2 into a
solid state for running on either JDK8 or JDK11 so folks can do
production upgrades on those releases. I'd like HBase 3 to be jdk11+
only so that we can reduce our test footprint in the project and start
to entertain features that don't work with jdk8. For example, we can't
start to figure out how we should fit in the module system as things
are.

= No more Log4j 1

We got through 95% of the work to make our logging system pluggable,
but we still ship with log4j 1 as the out of the box solution. I want
HBase 3 to ship with some other slf4j backend and I want that same
backend to be a realistic option for branch-2 users to deploy in
production.

= Minimize Hadoop needs

I would like to isolate the things we have that reach into Hadoop
internals so that we can ease the logistics of changing the Hadoop
version we run on and minimize the extra stuff we carry around for
those who don't run on Hadoop at all. This will involve moving the
stuff we have that reaches into internals into one or more module(s)
and updating our artifacts so that we can tell where our hadoop
related dependencies are in an installation.

Re: [DISCUSS] HBase 3 release plans

Posted by Sean Busbey <bu...@apache.org>.

If I may take the liberty of summarizing recent activity on the thread:

- Am I looking for any specifics in response
- Folks don't feel comfortable dropping JDK8 support in the HBase 3
timeframe (essentially 2021 - 2023)

For the first bit, thank you for calling that out Lars F. I'm not sure
why I missed my usual habit of making sure I have an explicit call to
action. You were correct that I'm generally looking for concerns and
other things folks would like to see included.

For JDK8 I'd rather not hold up HBase 3 planning, so I'm happy to
break off my concerns around keeping jdk8 around into a different
thread. At a minimum I'd like that thread to better detail what we as
a community see as the driving factor for when we'll drop jdk8. For
point of reference at least one commercial jdk support provider has a
published roadmap that keeps it supported through the end of 2030.

I think the discussion around ZK 3.5 and JUnit 5 were specific to the
JDK version talk. If we start from the assumption that JDK8 will be
the minimum required for HBase 3, do folks have strong feelings about
getting onto JUnit 5  or ZK3.5 for minimums on HBase 3? (again, for ZK
that would mean getting the work done so that HBase 2 works well at
run time with either ZK 3.4 or 3.5.)

On Fri, Feb 14, 2020 at 7:57 PM Sean Busbey <bu...@apache.org> wrote:
>
> Hi folks!
>
> Consider this the start of my release manager duties for HBase 3.0.0.
>
> HBase 2.0 started alpha releases in Jun 2017 and went GA in April
> 2018. I'd like to start alpha releases for HBase 3.0 next week and aim
> for a GA in December or January.
>
> As RM, I consider the alpha releases a chance for folks to shake
> things out and for us to decide as a community what makes it in or not
> for the release line. Once things start being labeled beta, I would
> like things to be feature frozen. My current goal is to set beta in
> May or June.
>
> I would like HBase 3.0 to be the start of us getting into practice on
> tighter iteration cycles for major versions. 2.5 years is too long. We
> should try to look at our version numbers as akin to Linux kernel
> version numbers. Something useful to those interested in the internals
> of the project but not something where most downstream users have to
> dread major bumps. To that end I would like HBase 3.0 to be rolling
> upgradable from HBase 2.y at GA. Ultimately, I would like to update
> our reference guide's section on compatibility to state that future
> major releases will similarly be rolling upgradable from some minor
> release of the prior major release line.
>
> Given my desire to make major upgrades less of a world changing event
> for our downstream folks, I also don't have any new features that I
> feel strongly need to make it into HBase 3.0. I'll do a review of
> what's currently there so we can motivate folks, but I won't do that
> until we're ready to declare beta since that will be when I'll have a
> better idea of what's actually ready to ship.
>
> With the major version change I'd like us to shed some maintenance
> burden in the project. For each of these, doing that will require
> getting a branch-2 release out that can successfully opt-in to the
> HBase 3 requirement and run on the current HBase 2 requirement. That
> way folks can do a rolling restart within HBase 2 to make the change,
> then do a rolling upgrade to HBase 3.
>
> = Hadoop 3 only
>
> The Hadoop community's focus increasingly is on Hadoop 3.y releases. A
> substantial amount of our dependency handling is tied to trying to
> span both Hadoop 2 and Hadoop 3. I would like us to drop Hadoop 2
> entirely. I think branch-2 is currently in a place where running on
> Hadoop 3 is reasonable.
>
> = JDK11+
>
> We've been bending over backwards on jdk versions for a while. Maven
> build sets up for multiple jdk builds are a PITA and our existing
> build is already too complicated. I'd like us to get branch-2 into a
> solid state for running on either JDK8 or JDK11 so folks can do
> production upgrades on those releases. I'd like HBase 3 to be jdk11+
> only so that we can reduce our test footprint in the project and start
> to entertain features that don't work with jdk8. For example, we can't
> start to figure out how we should fit in the module system as things
> are.
>
> = No more Log4j 1
>
> We got through 95% of the work to make our logging system pluggable,
> but we still ship with log4j 1 as the out of the box solution. I want
> HBase 3 to ship with some other slf4j backend and I want that same
> backend to be a realistic option for branch-2 users to deploy in
> production.
>
> = Minimize Hadoop needs
>
> I would like to isolate the things we have that reach into Hadoop
> internals so that we can ease the logistics of changing the Hadoop
> version we run on and minimize the extra stuff we carry around for
> those who don't run on Hadoop at all. This will involve moving the
> stuff we have that reaches into internals into one or more module(s)
> and updating our artifacts so that we can tell where our hadoop
> related dependencies are in an installation.