Yeah I'm currently working on HBASE-16591 to bring our master build
pipeline to jdk8 only...
2016-09-10 2:11 GMT+08:00 Josh Elser :
>
>
> Sean Busbey wrote:
>
>> This would be a very big breaking change in release numbering that goes
>> against our compatibility guidelines. We only drop support f
Sean Busbey wrote:
This would be a very big breaking change in release numbering that goes
against our compatibility guidelines. We only drop support for Java
versions on major releases.
If we want features that require newer jdks sooner, we should make major
releases sooner.
+1 On this exac
Agreed, makes sense interested parties should help Matteo get 2.0 out this
year. I'm on board.
On Fri, Sep 9, 2016 at 10:50 AM, Sean Busbey wrote:
> This would be a very big breaking change in release numbering that goes
> against our compatibility guidelines. We only drop support for Java
> ver
This would be a very big breaking change in release numbering that goes
against our compatibility guidelines. We only drop support for Java
versions on major releases.
If we want features that require newer jdks sooner, we should make major
releases sooner.
On Sep 8, 2016 20:54, "Duo Zhang" wrot
OK, I know. Thanks.
The layout of the table is broken so I misunderstood the meaning... I
thought the last five line in the table is only used to describe the
Server-Side Limited API...
2016年9月9日星期五，Andrew Purtell 写道：
> Our compatibility guidelines do not allow dropping support for a Java
>
Our compatibility guidelines do not allow dropping support for a Java version
in a minor or patch release by introducing code that won't link with the older
runtime: http://hbase.apache.org/book.html#hbase.versioning
See the Dependency Compatibility section in particular.
An upgrade of HBase w
So all the asynchronous api will be introduced in 2.0 only?
And java7 has been end of life for more than one year...
And also, for a upgrade, I do not think it is a good idea to upgrade JDK
and HBase together. So you always need to upgrade to jdk8 or later first at
some time before upgrading to a
I'd worry about doing this from both the client-server compatibility side
as well as for when it comes to upgrades. Having to go between Java
versions is way scarier for ops people than just swapping JARs.
On Thursday, September 8, 2016, Duo Zhang wrote:
> The main reason is the asynchronous api
Yeah, we should keep support for Java 7 in branch-1.
We can use CompletableFuture for 2.0 release.
On Thu, Sep 8, 2016 at 8:56 PM, Andrew Purtell
wrote:
> I think we should wait until 2.0 before dropping support for less than JDK
> 8. That's a pretty big deal. But, for 2.0, that would be fine I
I think we should wait until 2.0 before dropping support for less than JDK 8.
That's a pretty big deal. But, for 2.0, that would be fine IMHO.
> On Sep 8, 2016, at 8:54 PM, Duo Zhang wrote:
>
> The main reason is the asynchronous api we want to introduce in HBase
> today. See HBASE-13784 and H
The main reason is the asynchronous api we want to introduce in HBase
today. See HBASE-13784 and HBASE-16505.
The CompletableFuture in java8 is very suitable to use as the return value
of a async method. We can not use it if we still want to support java7, and
sadly, there is no candidate which is
11 matches
Mail list logo
