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
