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" <[email protected]> To: "Accumulo Dev List" <[email protected]> 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 <[email protected]> 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 <[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) > > > > -- > busbey >
