My understanding is that this proposal doesn't include any other changes other than bumping the required java version in the POM, but it does lay the groundwork for:
* Can more easily backport patches to 1.x that were originally written in the master branch (both for a custom user fork, or for our official upstream 1.x releases) * Future bugfixes on 1.x will be able to be written using lambdas and streams and other functional stuff in Java that can be merged into newer branches with significantly less developer work It just occurred to me to mention that it may be the case that bumping the required java version in the POM may trigger some minor code modifications to satisfy the modernizer-maven-plugin modernization checks, but those side effects are obviously not the primary intent. Ultimately, this seems to be about reducing the amount of work that developers need to do to both support an existing released version that they may have installed, as well as maintain and plan for the next version of Accumulo. Sean is right when he pointed out earlier in this thread that this is a tradeoff between developer needs against the operational user needs. I see it that way, too. However, while this proposal would help developers... I think it's ultimately it's about enabling those developers to more easily support their operational users who can't, or aren't ready to, upgrade to 2.x, for whatever reason. On Fri, Nov 1, 2019 at 3:06 PM Dave Marion <dmario...@gmail.com> wrote: > > Ed, > > At the point that 1.10 is released, would there be any Java 8 language > features used in the codebase? What exactly are you changing for the 1.10 > release, the compiler version in the pom, or more? > > On Fri, Nov 1, 2019 at 2:10 PM Michael Wall <mjw...@apache.org> wrote: > > > I am +1 on moving 1.10 to Java 8. > > > > However Sean's -1 vote is a veto [1] and we can not proceed down this path > > unless it is withdrawn. I can only take the veto to mean there are > > customers who would upgrade to Accumulo 1.10 but would not upgrade to Java > > 1.8. Is there anything that would change your mind Sean? > > > > Thanks > > > > Mike > > > > 1 - https://www.apache.org/foundation/voting.html#Veto > > > > > > On Fri, Nov 1, 2019 at 12:46 PM Sean Busbey <bus...@cloudera.com.invalid> > > wrote: > > > > > Correct, it is up to every user of SemVer to define the public API and > > > AFAIK we have chosen not to include things like the Java version > > > needed to run Accumulo in ours[1]. > > > > > > That doesn't mean it's not crappy to our downstream users to do things > > > that have a major operational impact upon minor releases. Updating a > > > JDK version is a major undertaking. It takes a long time to do in an > > > environment with strict change control policies and it sucks. There > > > are still shops that run JDK7. There are multiple options for > > > purchasing commercial support with security updates for it still. Just > > > picking two vendors out of the air[2], Oracle will still provide > > > support for almost 2 more years and Azul for almost 3. > > > > > > That doesn't mean we have to keep supporting JDK7, but be aware that > > > we are trading for a gain in developer convenience at the expense of > > > operator difficulty. We will probably drive folks into the arms of > > > forks that bother to maintain JDK compatibility for these release > > > lines. It does inhibit our ability to draw new folks into the > > > community, but that's not a fundamental problem I guess. > > > > > > As an aside, this comment from your cited FAQ is inaccurate on its > > > face for practical considerations in the Java ecosystem as cause for > > > not needing to worry about the downstream impact of changing a > > > dependency. > > > > > > > Software that explicitly depends on the same dependencies as your > > > package should have their own dependency specifications and the author > > will > > > notice any conflicts. > > > > > > We've discussed this a bunch of times. We clearly have disagreement in > > > the community about the priority on the tradeoff between developer > > > work and operational work. That's okay. > > > > > > [1]: https://accumulo.apache.org/api/ > > > [2]: https://www.azul.com/products/azul-support-roadmap/ > > > > > > On Fri, Nov 1, 2019 at 7:16 AM Ed Coleman <d...@etcoleman.com> wrote: > > > > > > > > If I am reading semver correctly ( > > > > > https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api > > ) > > > this proposal has no changes to the Accumulo public API, it is an update > > to > > > our dependencies - and would not require a major version change. > > > > > > > > -----Original Message----- > > > > From: Sean Busbey [mailto:bus...@cloudera.com.INVALID] > > > > Sent: Friday, November 01, 2019 3:52 AM > > > > To: dev@accumulo apache. org <dev@accumulo.apache.org> > > > > Subject: Re: [VOTE] Proposal to release version 1.10 > > > > > > > > -1 no dropping supported java versions in a minor release. if we want > > > folks to move to java 8 then we should make it easier to upgrade to > > > Accumulo 2.y > > > > > > > > On Thu, Oct 31, 2019 at 7:37 PM Ed Coleman <edcole...@apache.org> > > wrote: > > > > > > > > > > As suggested in the LTS discussion ([LAZY][VOTE] A basic, but > > > > > concrete, LTS proposal), I'm breaking this out to as a separate > > thread > > > > > to keep the topic distinct. > > > > > > > > > > > > > > > The proposal - I would like to start the formal release process for a > > > > > 1.10 version that would change the java language level to java 8. > > The > > > > > release would be based on the current 1.9 branch and would be > > released > > > > > instead of a 1.9.4. The 1.10 release would not contain additional > > > > > feature changes that are not present in the current 1.9 branch. > > > > > Currently, this would be based on the commit SHA: > > > > > > > > > > > > > > > 328ffa0849981e0f113dfbf539c832b447e06902 - committed Thu Oct 10. > > > > > > > > > > > > > > > (I am unaware of any bug-fixes or issues in the pipe line that would > > / > > > > > should be included - but hopefully this makes the intention clear.) > > > > > > > > > > > > > > > The goal is to provide a candidate for LTS nomination that is based > > on > > > > > the current 1.9.x code, but unifies our currently supported branches > > > > > to all use java 8 as the supported language level. While this had > > been > > > > > discussed in the past, enough time has passed that a java 8 > > > > > requirement now, seems to me, to be unlikely to impact any customers > > > > > that would look to upgrade Accumulo past a 1.9.3 version and have > > them > > > not running at least java 8. > > > > > Having our code base with a modern, unified java language support > > > > > level would greatly benefit our development and reduce the burden to > > > > > support our multiple branches. > > > > > > > > > > > > > > > This vote will be held open for at least the standard 72 hours. > > > > > > > > > > > > > > > > -- > > > > busbey > > > > > > > > > > > > > -- > > > busbey > > > > >
