Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <454430271.25529861.1462203831975.JavaMail.zimbra@comcast.net>
References: <57264E4B.1070901@gmail.com>
	<CAGHyZ6JTO3qUuXQL6NEgMoaAZBh=avJpDu4hsYx__d7FhCsreQ@mail.gmail.com>
	<CAGUtCHrQHnD-D1JJ0JBkxQZW-LaR7P--iWFBc3M=N4ipHYt0gw@mail.gmail.com>
	<454430271.25529861.1462203831975.JavaMail.zimbra@comcast.net>
Date: Mon, 2 May 2016 11:54:05 -0400
Message-ID: <CAGUtCHoTfc1=JhjaWOvz+=JiE0s=VZ46QcKmt7LO6Bw+fb0sUg@mail.gmail.com>
Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented]
 (ACCUMULO-4177) TinyLFU-based BlockCache)
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11354f4a8fe47b0531de00bf
archived-at: Mon, 02 May 2016 15:54:12 -0000

--001a11354f4a8fe47b0531de00bf
Content-Type: text/plain; charset=UTF-8

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, <dlmarion@comcast.net> 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" <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
> >
>
>

--001a11354f4a8fe47b0531de00bf--