I understand we can bump it whenever we want and I am not opposed to jumping to 2.0. I am pondering the case where we jump to 2.0.0-SNAP because of JDK8 and then someone later drops deprecated methods, even though that was not the intent of jumping to 2.0.0-SNAP.
On Mon, May 2, 2016 at 11:43 AM, <[email protected]> wrote: > 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 > > > >
