You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Ed Coleman <ed...@apache.org> on 2019/11/01 00:36:54 UTC
[VOTE] Proposal to release version 1.10
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.
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
+1 to creating a 1.10.0 derived from 1.9 that bumps the Java
requirement to 8, and doing so instead of releasing 1.9.4.
I think the java version bump will help with maintaining patches that
can be more easily backported to 1.x. If this vote passes, I will
advocate for 1.10 to be used as the LTS instead of 1.9 in the LTS
discussion.
On Thu, Oct 31, 2019 at 8:37 PM Ed Coleman <ed...@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.
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
On Mon, Nov 4, 2019 at 11:28 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Fri, Nov 1, 2019 at 12:46 PM Sean Busbey <bu...@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.
>
I think that's a good point, in general, for the LTS strategy that
we've been discussing in the other thread. It'd still be *possible* to
release patches for non-LTS releases... we just wouldn't *normally* do
it, to minimize the work. But, if it's really serious, and somebody's
willing to do the work, then it could still happen occasionally.
Re: [VOTE] Proposal to release version 1.10
Posted by Keith Turner <ke...@deenlo.com>.
On Fri, Nov 1, 2019 at 12:46 PM Sean Busbey <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > Sent: Friday, November 01, 2019 3:52 AM
> > To: dev@accumulo apache. org <de...@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 <ed...@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
Re: [VOTE] Proposal to release version 1.10
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
I don't understand the question on my -1. My intention doesn't matter.
We have bylaws as a project and the foundation has bylaws where there
are gaps; this combination makes clear what the rules are for any
vote. AFAICT this vote should be a majority vote.
Two things that we could have done better here:
1) VOTEs should be a formality of expressing what we already know the
position of the community to be. That folks are so surprised and
blocked up on me following up is a sign that there should have been an
appropriately labeled DISCUSS thread. Please do that in the future.
2) To make things clearer for folks, expressly state what the voting
rules are when announcing the vote. If you can't work out what they
should be from the bylaws, then ask before calling a vote.
On Tue, Nov 5, 2019 at 9:55 AM Sean Busbey <bu...@cloudera.com> wrote:
>
> Yeah I'm reading messages now.
>
> On Tue, Nov 5, 2019 at 6:32 AM Christopher <ct...@apache.org> wrote:
> >
> > 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 <ct...@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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > > > > Sent: Friday, November 01, 2019 3:52 AM
> > > > > > To: dev@accumulo apache. org <de...@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 <ed...@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
> > > > >
>
>
>
> --
> busbey
--
busbey
Re: [VOTE] Proposal to release version 1.10
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
Yeah I'm reading messages now.
On Tue, Nov 5, 2019 at 6:32 AM Christopher <ct...@apache.org> wrote:
>
> 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 <ct...@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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > > > Sent: Friday, November 01, 2019 3:52 AM
> > > > > To: dev@accumulo apache. org <de...@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 <ed...@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
> > > >
--
busbey
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
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 <ct...@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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > > Sent: Friday, November 01, 2019 3:52 AM
> > > > To: dev@accumulo apache. org <de...@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 <ed...@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
> > >
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > Sent: Friday, November 01, 2019 3:52 AM
> > > To: dev@accumulo apache. org <de...@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 <ed...@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
> >
Re: [VOTE] Proposal to release version 1.10
Posted by Keith Turner <ke...@deenlo.com>.
On Fri, Nov 1, 2019 at 4:04 PM Christopher <ct...@apache.org> wrote:
>
> 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)
Switching to Java 8 will make backporting easier in some cases.
However for some cases, the significant internal Accumulo changes
between 1.9 and 2.0 make back porting difficult regardless of the Java
version. Not sure what the proportions are. When I have merged
forward and back, it seems like these internal Accumuo changes were
the time sinks. The Java 7 vs Java 8 issues were annoying, but
usually not very time consuming (ugh, I have to change a map.forEach
to a forEach loop).
> * 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 <dm...@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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > > > Sent: Friday, November 01, 2019 3:52 AM
> > > > > To: dev@accumulo apache. org <de...@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 <ed...@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
> > > >
> > >
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
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 <dm...@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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > > Sent: Friday, November 01, 2019 3:52 AM
> > > > To: dev@accumulo apache. org <de...@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 <ed...@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
> > >
> >
Re: [VOTE] Proposal to release version 1.10
Posted by Dave Marion <dm...@gmail.com>.
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 <mj...@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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > > Sent: Friday, November 01, 2019 3:52 AM
> > > To: dev@accumulo apache. org <de...@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 <ed...@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
> >
>
Re: [VOTE] Proposal to release version 1.10
Posted by Michael Wall <mj...@apache.org>.
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 <bu...@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 <de...@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:busbey@cloudera.com.INVALID]
> > Sent: Friday, November 01, 2019 3:52 AM
> > To: dev@accumulo apache. org <de...@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 <ed...@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
>
Re: [VOTE] Proposal to release version 1.10
Posted by Christopher <ct...@apache.org>.
On Fri, Nov 1, 2019 at 12:46 PM Sean Busbey <bu...@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].
I don't interpret our previous decision to not bump Java version in
1.x as a permanent one, but one based on circumstances at the time.
This is not enshrined in our public API definition at the referenced
link, and we've already made other Java version bumps in a major
version (from 1.6 to 1.7 in Accumulo 1.7.0, albeit prior to adopting
semver, and we're doing 2.1 development on Java 11 today), so there is
precedent.
I think the most significant point is that circumstances have changed
since the last time we discussed this. Java 8 has been EOL for awhile
now, and Java upstream has established a very different release
cadence, establishing very different expectations for developers and
end users with respect to upgrades. I think it is reasonable to expect
that the vast majority of users willing to upgrade to 1.10 would
already be using at least Java 8, or be willing to do so.
Re: [VOTE] Proposal to release version 1.10
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
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 <de...@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:busbey@cloudera.com.INVALID]
> Sent: Friday, November 01, 2019 3:52 AM
> To: dev@accumulo apache. org <de...@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 <ed...@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
Re: [VOTE] Proposal to release version 1.10
Posted by Mike Miller <mm...@apache.org>.
+1
This would line up our LTS versions with Java's LTS labeling:
https://en.wikipedia.org/wiki/Java_version_history
On Fri, Nov 1, 2019 at 10:56 AM Adam Lerman <al...@gmail.com> wrote:
> +1
>
> On Fri, Nov 1, 2019 at 8:16 AM Ed Coleman <de...@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:busbey@cloudera.com.INVALID]
> > Sent: Friday, November 01, 2019 3:52 AM
> > To: dev@accumulo apache. org <de...@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 <ed...@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
> >
> >
>
Re: [VOTE] Proposal to release version 1.10
Posted by Adam Lerman <al...@gmail.com>.
+1
On Fri, Nov 1, 2019 at 8:16 AM Ed Coleman <de...@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:busbey@cloudera.com.INVALID]
> Sent: Friday, November 01, 2019 3:52 AM
> To: dev@accumulo apache. org <de...@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 <ed...@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
>
>
RE: [VOTE] Proposal to release version 1.10
Posted by Ed Coleman <de...@etcoleman.com>.
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:busbey@cloudera.com.INVALID]
Sent: Friday, November 01, 2019 3:52 AM
To: dev@accumulo apache. org <de...@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 <ed...@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
Re: [VOTE] Proposal to release version 1.10
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
-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 <ed...@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
Re: [VOTE] Proposal to release version 1.10
Posted by Keith Turner <ke...@deenlo.com>.
+0
I think this is slightly confusing from a users perspective. However,
I think this concern is easily addressed with well written release
notes explaining why 1.10 exists and how it fits into the bigger
picture of 1.9 and 2.0.
I am not opposed to this, but I am not sure how much I can help. This
seems like it could take a lot of time to do well. I would personally
rather spend that time on 2.1.0 features.
Keith
On Thu, Oct 31, 2019 at 8:37 PM Ed Coleman <ed...@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.