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 > > >
