For me the only concern is the JDK11+. As long as lots of big company are starting to make their own OpenJDK8 releases(like AdoptOpenJDK from redhat, and corretto from Amazon, and so on), at least a big part of java world will still be on JDK8, this means we still need to run HBase 2 for a very long time?
Lars Francke <lars.fran...@gmail.com> 于2020年2月17日周一 下午6:45写道： > Sean, > > you didn't have any explicit questions or request for feedback in your mail > so I'll just say that from my point all the points from your mail make > sense to me and I'm +1 on all of them. > > - Timeline (GA December/January) > - Start of shorter release cycle > - Rolling upgrade > - JDK11+ > - Hadoop 3 only > - No more Log4j 1 > - Minimize Hadoop needs > > Thank you for starting this process! > > On Sat, Feb 15, 2020 at 2:55 AM Sean Busbey <bus...@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. > > >
