Wasn't 1.7.0 pre SemVer? On Mon, May 2, 2016 at 8:55 AM, Josh Elser <[email protected]> wrote:
> Thanks for the input, Sean. > > Playing devil's advocate: we didn't have a major version bump when we > dropped JDK6 support (in Accumulo-1.7.0). Oracle has EOL'ed java 7 back in > April 2015. Was the 6->7 upgrade different than a 7->8 upgrade? > > > Sean Busbey wrote: > >> If we drop jdk7 support, I would strongly prefer a major version bump. >> >> On Sun, May 1, 2016 at 1:43 PM, Josh Elser<[email protected]> 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)<[email protected]> >>> Reply-To: [email protected] >>> To: [email protected] >>> >>> >>> [ >>> >>> 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) >>> >> >> >> >>
