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
>
> What about the connectors repo?
>
Spark 3.0 will support Java 8/11 once it is released, so we have to upgrade
our codebase to ensure compatibility with Spark 3. Kafka client should
work with Java 11 as well.
> What about the operator tools?
>
It shouldn't be an issue.
Agreed. The major version change is the best (only?) time to do it.
However your helpful details shed light on what I meant about potentially
hidden work in moving up to JDK 11. I agree we should Upgrade to ZK 3.5. Did
they solve the test issues for 3.4? Last I checked not so long ago it was st
Although I'm not a committer and mostly not that active on the HBase list I
think I can share some valuable information/ideas:
"Only if a post 8 language feature becomes compelling should there be any
need to move up the bytecode compatibility line. Any thoughts there. I
can’t think of a one. Even
The flip side, which favors the idea of upgrading, is if all our dependencies
or related projects are moving up but we are not then we are the rock that may
prevent a user from upgrading the whole stack otherwise.
I was trying to articulate a compromise position earlier: Building for release
o
The comment on the JRuby shell sounded like a proposal to replace based on a
personal dislike. I apologize given your clarification.
JRuby may not be loved but it’s the only basis for scripted automation we have
right now and there are compatibility concerns regards any proposals to replace.
W
On Mon, Feb 17, 2020 at 8:18 PM Andrew Purtell
wrote:
> I realize re reading this I left my point incomplete. Pardon, here is the
> rest of it:
>
> That said, if the consensus emerges that moving up to and taking a
> dependency on Java 11 is the best thing to do (for benefits ??, at least
> one b
On Mon, Feb 17, 2020 at 7:53 PM Andrew Purtell
wrote:
> On the topic of JRuby, we have operational tooling based on this precisely
> because HBase offers a shell built on it where the shell function
> themselves can be used as functions, per design. You want us to throw this
> all away because yo
I realize re reading this I left my point incomplete. Pardon, here is the rest
of it:
That said, if the consensus emerges that moving up to and taking a dependency
on Java 11 is the best thing to do (for benefits ??, at least one being a
certification of sorts we run on a LTS > 8), then we ackn
On the topic of JRuby, we have operational tooling based on this precisely
because HBase offers a shell built on it where the shell function themselves
can be used as functions, per design. You want us to throw this all away
because you don’t like JRuby? Or want to play with some new language? H
A user can upgrade their runtime to 11 and deploy software built on 8 at their
option at any time. Staying on 8 doesn’t affect this one way or another.
Are we in the business of Java language evangelism or adoption? No. So as PMC I
am -1 on taking on such orthogonal missions.
When you run ZK
I don't have a super-strong opinion on this but one of the reasons I'm in
favor of moving to 11 is actually to apply some pressure.
OpenJDK is in all the major package repositories as far as I know. This is
different from the Oracle JDK. So it's relatively simple to upgrade.
Lots of our customers
I share this concern.
I recommend we build on 8, so can run on any 8 or later runtime, and test on 11
or whatever the desired next advertised version of the runtime will be. Builds
and unit tests would execute on 8, then whole stack integration tests on 11
(like ITBLL).
Only if a post 8 langu
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 lo
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 o
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
16 matches
Mail list logo
