Sean, can you please reply to this and answer the question regarding your -1? Thanks.
On Fri, Nov 1, 2019 at 2:40 PM Christopher <ctubb...@apache.org> wrote: > > I'm not actually sure if this would be considered a veto, or just a -1 > on a majority vote. Vetos are used for code changes and are > accompanied by technical justifications. This isn't vetoing a code > change based on a technical justification. We're merely deciding on a > release plan, and the justification appears less technical than social > (managing user expectations and upgrade requirements) although I > suppose these lines can be blurred, because everything we do is about > both people and technology. My assumption is that votes like this are > typically majority voting, but the fact that this isn't 100% clear is > something that has always bugged me in the ASF. > > I guess the best thing to do is ask Sean: are you intending your -1 as > a veto against any change that would move us in the direction of the > proposed plan, or are you willing to permit the majority decision to > stand here, whichever way it ends up going? > > 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 > > >
