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
Personally I don't think creating a 1.10 line should preclude ever releasing another 1.9. If a really serious bug is found and someone wants to fix it in 1.9 and do the work to make a release happen, then I would support them. Practically, though we want to minimize the amount of work everyone has to do and this is just more work for someone. > 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
