accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Mon, 02 May 2016 15:43:51 GMT
SemVer mandates a major version bump when incompatible API changes are made, but it does not
disallow us from bumping it when ever we want. This case is addressed in [1]. I was suggesting
releasing it as 2.0 as a signal to our users that something important has changed. I could
be easily convinced to leave it at 1.8. 

[1] http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api


----- Original Message -----

From: "Keith Turner" <keith@deenlo.com> 
To: "Accumulo Dev List" <dev@accumulo.apache.org> 
Sent: Monday, May 2, 2016 11:31:58 AM 
Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based
BlockCache) 

On Mon, May 2, 2016 at 1:54 AM, Sean Busbey <busbey@cloudera.com> wrote: 

> If we drop jdk7 support, I would strongly prefer a major version bump. 
> 


Whats the rationale for binding a bump to Accumulo 2.0 with a bump in the 
JDK version? 

Bumping the major version w/ semvers means that incompatible API changes 
were made like dropping deprecated methods. I am thinking the decision to 
jump to 2.0 should be based on a desire/need to drop deprecated methods, 
which seems like a separate vote. 


> 
> On Sun, May 1, 2016 at 1:43 PM, Josh Elser <josh.elser@gmail.com> wrote: 
> > Folks -- 
> > 
> > Let's come up with a plan for Java 8 support. Do we bump minJdk for 
> > accumulo-1.8.0 to 8? Should we fork a branch for 1.8 and make master 
> > 2.0.0-SNAPSHOT (and do the bump there)? 
> > 
> > Other approaches? 
> > 
> > - Josh 
> > 
> > -------- Original Message -------- 
> > Subject: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache 
> > Date: Sat, 30 Apr 2016 01:06:12 +0000 (UTC) 
> > From: Ben Manes (JIRA) <jira@apache.org> 
> > Reply-To: jira@apache.org 
> > To: notifications@accumulo.apache.org 
> > 
> > 
> > [ 
> > 
> https://issues.apache.org/jira/browse/ACCUMULO-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15265032#comment-15265032

> > ] 
> > 
> > Ben Manes commented on ACCUMULO-4177: 
> > ------------------------------------- 
> > 
> > I can put something together when Accumulo is ready to accept Java 8 
> > patches. Let me know. 
> > 
> >> TinyLFU-based BlockCache 
> >> ------------------------ 
> >> 
> >> Key: ACCUMULO-4177 
> >> URL: 
> https://issues.apache.org/jira/browse/ACCUMULO-4177 
> >> Project: Accumulo 
> >> Issue Type: Improvement 
> >> Reporter: Ben Manes 
> >> 
> >> 
> >> [LruBlockCache| 
> https://github.com/apache/accumulo/blob/master/core/src/main/java/org/apache/accumulo/core/file/blockfile/cache/LruBlockCache.java

> ] 
> >> appears to be based on HBase's. I currently have a patch being reviewed 
> in 
> >> [HBASE-15560|https://issues.apache.org/jira/browse/HBASE-15560] that 
> >> replaces the pseudo Segmented LRU with the TinyLFU eviction policy. That 
> >> should allow the cache to make [better 
> >> predictions|https://github.com/ben-manes/caffeine/wiki/Efficiency] 
> based on 
> >> frequency and recency, such as improved scan resistance. The 
> implementation 
> >> uses [Caffeine|https://github.com/ben-manes/caffeine], the successor to 
> >> Guava's cache, to provide concurrency and keep the patch small. 
> >> Full details are in the JIRA ticket. I think it should be easy to port 
> if 
> >> there is interest. 
> > 
> > 
> > 
> > 
> > -- 
> > This message was sent by Atlassian JIRA 
> > (v6.3.4#6332) 
> 
> 
> 
> -- 
> busbey 
> 


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