I think Mike meant "Accumulo wasn't following SemVer".
To your question, Mike, per https://accumulo.apache.org/versioning.html
"The Apache Accumulo PMC closed a vote on 2014/12/12 which adopted
Semantic Versioning 2.0.0 as the reference document"
According to reporter.a.o, 1.7.0 was released 2015/05/15.
I think that means by the time 1.7.0 landed, we were well versed in
doing semver properly (maybe it was the 1.6 line that wasn't?).
William Slacum wrote:
Kind of hard to pull the semver card when java 1.7 technically isn't semver
compliant.
On Mon, May 2, 2016 at 10:31 AM, Mike Drob<md...@apache.org> wrote:
Wasn't 1.7.0 pre SemVer?
On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.el...@gmail.com> 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<josh.el...@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)<j...@apache.org>
Reply-To: j...@apache.org
To: notificati...@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)
