[DISCUSS] Java 8

[Christopher <ct...@apache.org>]

I know we've talked about this before, but I kind of want to just use Java
8 for Accumulo 1.8. It'd help clean up some things in the build (can make
use of newer versions of build plugins, and make it easier for new
development against the latest release).

I just don't know how reasonable it is to keep making new, non-bugfix
releases on EOL JDKs (even though I may have previously argued that it'd be
safer to just wait until a major version bump).

Re: [DISCUSS] Java 8

[Josh Elser <jo...@gmail.com>]

+1 on your suggestion, Sean.

Changing what 1.8 is at the 11th hour does not sit well with me. There 
is no reason we cannot finish 1.8 as it stands, and then do the JDK8 
switch for a 2.0 (and release it in whatever rapid succession is desired).

Sean Busbey wrote:
> I'm all for moving us towards java 8+ only, but I'm still -1 on
> dropping java 7 in a minor release. Plenty of folks still run Java 7
> in production. I'm sure a non-zero number of them will want to update
> versions and a major version is how we communicate that level of
> expected disruption.
>
> How about we get 1.8 out the door with Java 7 + Java 8, then try to
> get master out the door with Java 8 as the minimum version? What's the
> blocker on a release from master now?
>
> On Thu, Aug 18, 2016 at 5:46 PM, Christopher<ct...@apache.org>  wrote:
>> We need to make sure this release works with Java 8 anyway... but this
>> change would tighten things up a bit, so we don't have to worry about
>> supporting Java 7. It narrows our testing and allows us to focus on just
>> the non-EOL, modern Java versions that we should be realistically expecting
>> users of Accumulo 1.8 to be using anyway.
>>
>> On Thu, Aug 18, 2016 at 6:37 PM Josh Elser<jo...@gmail.com>  wrote:
>>
>>> Err, I am not a big fan of making this change after two rc's and all of
>>> the testing I've been babysitting this week.
>>>
>>> I have no problem with you spinning a 2.0 which is 99% similar to 1.8
>>> with whatever else you'd like to do (in fact, I'd encourage anyone to
>>> step up and drive 2.0 to release).
>>>
>>> Sean Busbey wrote:
>>>> Why don't we just make the 1.8 branch 2.0 then? I really don't want to
>>>> drop support for JDKs on non-major releases; it's super disruptive.
>>>>
>>>> On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
>>> wrote:
>>>>> I know we've talked about this before, but I kind of want to just use
>>> Java
>>>>> 8 for Accumulo 1.8. It'd help clean up some things in the build (can
>>> make
>>>>> use of newer versions of build plugins, and make it easier for new
>>>>> development against the latest release).
>>>>>
>>>>> I just don't know how reasonable it is to keep making new, non-bugfix
>>>>> releases on EOL JDKs (even though I may have previously argued that
>>> it'd be
>>>>> safer to just wait until a major version bump).
>>>>
>>>>
>
>
>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

There seem to be differences of opinion about what action to take (or not
take), but I think everybody understands the relevant concerns which have
been expressed so far. I'm going to let this thread sit for the weekend so
folks can think and comment some more, and then call a vote on Monday to
decide on the action to take. I think that's probably the best way to
resolve this clearly... let the majority decide so we're not in a stalemate.

FWIW, I also took a look at what's in the master branch, and there's not
much differences from 1.8, except some mostly superficial improvements for
JDK8... not much actual changes. This biggest concern
is b69291a3453fd0e6091586cf37fb1636a356caa9 which aggressively drops
Deprecated code. I think that could be reverted relatively easily, and we
could release from the current master. It's not in as bad a state as I had
thought... and the bad state that is there were a result of that commit.

On Fri, Aug 19, 2016 at 1:08 PM Christopher <ct...@apache.org> wrote:

> Re-reading the old thread, I'm reminded that we actually can't bump
> without either disabling the modernizer plugin or making some minimal
> breaking changes in mock (which is already deprecated). That's not
> necessarily a problem for a major version bump, but it means that it
> wouldn't necessarily be a name-only change, unless we disable modernizer.
>
> On Thu, Aug 18, 2016 at 7:30 PM Christopher <ct...@apache.org> wrote:
>
>> Yes, and we ended up going with the "defer" option instead of the two
>> subsequent releases option. Given my concerns about spreading ourselves too
>> thin, I think I'd prefer to again punt this change, rather than try to
>> support two subsequent releases like this.
>>
>> On Thu, Aug 18, 2016 at 7:23 PM Dave Marion <dm...@gmail.com> wrote:
>>
>>> I think we discussed this previously. If I remember correctly, I
>>> suggested,
>>> in this case, releasing 1.x as is, closely followed by a 2.0 with newer
>>> dependencies and deprecated items removed and much the same features.
>>>
>>> Found it:
>>> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201605.mbox/
>>> <21...@comcast.net>
>>>
>>> On Aug 18, 2016 7:13 PM, "Christopher" <ct...@apache.org> wrote:
>>>
>>> > Oh, master is in a terrible state (test instabilities). I wouldn't
>>> think
>>> > it's even close. Trying to support 1.6, 1.7, and working towards 1.8,
>>> > there's nothing left for working on master.
>>> >
>>> > If we wanted to do a quick 2.0 release and a Java 7 1.8 release, we can
>>> > fork a 2.0 from 1.8 for JDK 8.
>>> >
>>> > My main concern with this suggestion, though, is the need to continue
>>> to
>>> > support 4x branches. 1.7, 1.8, 2.0, and whatever master becomes
>>> (probably
>>> > 3.0). I think it'll spread us far too thin (I think we're already too
>>> > thin), and I don't think we can afford to drop 1.7, like we can for
>>> 1.6,
>>> > because 1.8 hasn't been "in the wild" long enough yet, and we should
>>> > continue to support 1.7.
>>> >
>>> > On Thu, Aug 18, 2016 at 6:50 PM Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>> >
>>> > > I'm all for moving us towards java 8+ only, but I'm still -1 on
>>> > > dropping java 7 in a minor release. Plenty of folks still run Java 7
>>> > > in production. I'm sure a non-zero number of them will want to update
>>> > > versions and a major version is how we communicate that level of
>>> > > expected disruption.
>>> > >
>>> > > How about we get 1.8 out the door with Java 7 + Java 8, then try to
>>> > > get master out the door with Java 8 as the minimum version? What's
>>> the
>>> > > blocker on a release from master now?
>>> > >
>>> > > On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org>
>>> > wrote:
>>> > > > We need to make sure this release works with Java 8 anyway... but
>>> this
>>> > > > change would tighten things up a bit, so we don't have to worry
>>> about
>>> > > > supporting Java 7. It narrows our testing and allows us to focus on
>>> > just
>>> > > > the non-EOL, modern Java versions that we should be realistically
>>> > > expecting
>>> > > > users of Accumulo 1.8 to be using anyway.
>>> > > >
>>> > > > On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com>
>>> > wrote:
>>> > > >
>>> > > >> Err, I am not a big fan of making this change after two rc's and
>>> all
>>> > of
>>> > > >> the testing I've been babysitting this week.
>>> > > >>
>>> > > >> I have no problem with you spinning a 2.0 which is 99% similar to
>>> 1.8
>>> > > >> with whatever else you'd like to do (in fact, I'd encourage
>>> anyone to
>>> > > >> step up and drive 2.0 to release).
>>> > > >>
>>> > > >> Sean Busbey wrote:
>>> > > >> > Why don't we just make the 1.8 branch 2.0 then? I really don't
>>> want
>>> > to
>>> > > >> > drop support for JDKs on non-major releases; it's super
>>> disruptive.
>>> > > >> >
>>> > > >> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<
>>> ctubbsii@apache.org>
>>> > > >> wrote:
>>> > > >> >> I know we've talked about this before, but I kind of want to
>>> just
>>> > use
>>> > > >> Java
>>> > > >> >> 8 for Accumulo 1.8. It'd help clean up some things in the build
>>> > (can
>>> > > >> make
>>> > > >> >> use of newer versions of build plugins, and make it easier for
>>> new
>>> > > >> >> development against the latest release).
>>> > > >> >>
>>> > > >> >> I just don't know how reasonable it is to keep making new,
>>> > non-bugfix
>>> > > >> >> releases on EOL JDKs (even though I may have previously argued
>>> that
>>> > > >> it'd be
>>> > > >> >> safer to just wait until a major version bump).
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > busbey
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

Re-reading the old thread, I'm reminded that we actually can't bump without
either disabling the modernizer plugin or making some minimal breaking
changes in mock (which is already deprecated). That's not necessarily a
problem for a major version bump, but it means that it wouldn't necessarily
be a name-only change, unless we disable modernizer.

On Thu, Aug 18, 2016 at 7:30 PM Christopher <ct...@apache.org> wrote:

> Yes, and we ended up going with the "defer" option instead of the two
> subsequent releases option. Given my concerns about spreading ourselves too
> thin, I think I'd prefer to again punt this change, rather than try to
> support two subsequent releases like this.
>
> On Thu, Aug 18, 2016 at 7:23 PM Dave Marion <dm...@gmail.com> wrote:
>
>> I think we discussed this previously. If I remember correctly, I
>> suggested,
>> in this case, releasing 1.x as is, closely followed by a 2.0 with newer
>> dependencies and deprecated items removed and much the same features.
>>
>> Found it:
>> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201605.mbox/
>> <21...@comcast.net>
>>
>> On Aug 18, 2016 7:13 PM, "Christopher" <ct...@apache.org> wrote:
>>
>> > Oh, master is in a terrible state (test instabilities). I wouldn't think
>> > it's even close. Trying to support 1.6, 1.7, and working towards 1.8,
>> > there's nothing left for working on master.
>> >
>> > If we wanted to do a quick 2.0 release and a Java 7 1.8 release, we can
>> > fork a 2.0 from 1.8 for JDK 8.
>> >
>> > My main concern with this suggestion, though, is the need to continue to
>> > support 4x branches. 1.7, 1.8, 2.0, and whatever master becomes
>> (probably
>> > 3.0). I think it'll spread us far too thin (I think we're already too
>> > thin), and I don't think we can afford to drop 1.7, like we can for 1.6,
>> > because 1.8 hasn't been "in the wild" long enough yet, and we should
>> > continue to support 1.7.
>> >
>> > On Thu, Aug 18, 2016 at 6:50 PM Sean Busbey <bu...@cloudera.com>
>> wrote:
>> >
>> > > I'm all for moving us towards java 8+ only, but I'm still -1 on
>> > > dropping java 7 in a minor release. Plenty of folks still run Java 7
>> > > in production. I'm sure a non-zero number of them will want to update
>> > > versions and a major version is how we communicate that level of
>> > > expected disruption.
>> > >
>> > > How about we get 1.8 out the door with Java 7 + Java 8, then try to
>> > > get master out the door with Java 8 as the minimum version? What's the
>> > > blocker on a release from master now?
>> > >
>> > > On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org>
>> > wrote:
>> > > > We need to make sure this release works with Java 8 anyway... but
>> this
>> > > > change would tighten things up a bit, so we don't have to worry
>> about
>> > > > supporting Java 7. It narrows our testing and allows us to focus on
>> > just
>> > > > the non-EOL, modern Java versions that we should be realistically
>> > > expecting
>> > > > users of Accumulo 1.8 to be using anyway.
>> > > >
>> > > > On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com>
>> > wrote:
>> > > >
>> > > >> Err, I am not a big fan of making this change after two rc's and
>> all
>> > of
>> > > >> the testing I've been babysitting this week.
>> > > >>
>> > > >> I have no problem with you spinning a 2.0 which is 99% similar to
>> 1.8
>> > > >> with whatever else you'd like to do (in fact, I'd encourage anyone
>> to
>> > > >> step up and drive 2.0 to release).
>> > > >>
>> > > >> Sean Busbey wrote:
>> > > >> > Why don't we just make the 1.8 branch 2.0 then? I really don't
>> want
>> > to
>> > > >> > drop support for JDKs on non-major releases; it's super
>> disruptive.
>> > > >> >
>> > > >> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ctubbsii@apache.org
>> >
>> > > >> wrote:
>> > > >> >> I know we've talked about this before, but I kind of want to
>> just
>> > use
>> > > >> Java
>> > > >> >> 8 for Accumulo 1.8. It'd help clean up some things in the build
>> > (can
>> > > >> make
>> > > >> >> use of newer versions of build plugins, and make it easier for
>> new
>> > > >> >> development against the latest release).
>> > > >> >>
>> > > >> >> I just don't know how reasonable it is to keep making new,
>> > non-bugfix
>> > > >> >> releases on EOL JDKs (even though I may have previously argued
>> that
>> > > >> it'd be
>> > > >> >> safer to just wait until a major version bump).
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> > >
>> > >
>> > > --
>> > > busbey
>> > >
>> >
>>
>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

Yes, and we ended up going with the "defer" option instead of the two
subsequent releases option. Given my concerns about spreading ourselves too
thin, I think I'd prefer to again punt this change, rather than try to
support two subsequent releases like this.

On Thu, Aug 18, 2016 at 7:23 PM Dave Marion <dm...@gmail.com> wrote:

> I think we discussed this previously. If I remember correctly, I suggested,
> in this case, releasing 1.x as is, closely followed by a 2.0 with newer
> dependencies and deprecated items removed and much the same features.
>
> Found it:
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201605.mbox/
> <21...@comcast.net>
>
> On Aug 18, 2016 7:13 PM, "Christopher" <ct...@apache.org> wrote:
>
> > Oh, master is in a terrible state (test instabilities). I wouldn't think
> > it's even close. Trying to support 1.6, 1.7, and working towards 1.8,
> > there's nothing left for working on master.
> >
> > If we wanted to do a quick 2.0 release and a Java 7 1.8 release, we can
> > fork a 2.0 from 1.8 for JDK 8.
> >
> > My main concern with this suggestion, though, is the need to continue to
> > support 4x branches. 1.7, 1.8, 2.0, and whatever master becomes (probably
> > 3.0). I think it'll spread us far too thin (I think we're already too
> > thin), and I don't think we can afford to drop 1.7, like we can for 1.6,
> > because 1.8 hasn't been "in the wild" long enough yet, and we should
> > continue to support 1.7.
> >
> > On Thu, Aug 18, 2016 at 6:50 PM Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > I'm all for moving us towards java 8+ only, but I'm still -1 on
> > > dropping java 7 in a minor release. Plenty of folks still run Java 7
> > > in production. I'm sure a non-zero number of them will want to update
> > > versions and a major version is how we communicate that level of
> > > expected disruption.
> > >
> > > How about we get 1.8 out the door with Java 7 + Java 8, then try to
> > > get master out the door with Java 8 as the minimum version? What's the
> > > blocker on a release from master now?
> > >
> > > On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org>
> > wrote:
> > > > We need to make sure this release works with Java 8 anyway... but
> this
> > > > change would tighten things up a bit, so we don't have to worry about
> > > > supporting Java 7. It narrows our testing and allows us to focus on
> > just
> > > > the non-EOL, modern Java versions that we should be realistically
> > > expecting
> > > > users of Accumulo 1.8 to be using anyway.
> > > >
> > > > On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com>
> > wrote:
> > > >
> > > >> Err, I am not a big fan of making this change after two rc's and all
> > of
> > > >> the testing I've been babysitting this week.
> > > >>
> > > >> I have no problem with you spinning a 2.0 which is 99% similar to
> 1.8
> > > >> with whatever else you'd like to do (in fact, I'd encourage anyone
> to
> > > >> step up and drive 2.0 to release).
> > > >>
> > > >> Sean Busbey wrote:
> > > >> > Why don't we just make the 1.8 branch 2.0 then? I really don't
> want
> > to
> > > >> > drop support for JDKs on non-major releases; it's super
> disruptive.
> > > >> >
> > > >> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
> > > >> wrote:
> > > >> >> I know we've talked about this before, but I kind of want to just
> > use
> > > >> Java
> > > >> >> 8 for Accumulo 1.8. It'd help clean up some things in the build
> > (can
> > > >> make
> > > >> >> use of newer versions of build plugins, and make it easier for
> new
> > > >> >> development against the latest release).
> > > >> >>
> > > >> >> I just don't know how reasonable it is to keep making new,
> > non-bugfix
> > > >> >> releases on EOL JDKs (even though I may have previously argued
> that
> > > >> it'd be
> > > >> >> safer to just wait until a major version bump).
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > >
> > >
> > >
> > > --
> > > busbey
> > >
> >
>

Re: [DISCUSS] Java 8

[Dave Marion <dm...@gmail.com>]

I think we discussed this previously. If I remember correctly, I suggested,
in this case, releasing 1.x as is, closely followed by a 2.0 with newer
dependencies and deprecated items removed and much the same features.

Found it: http://mail-archives.apache.org/mod_mbox/accumulo-dev/201605.mbox/
<21...@comcast.net>

On Aug 18, 2016 7:13 PM, "Christopher" <ct...@apache.org> wrote:

> Oh, master is in a terrible state (test instabilities). I wouldn't think
> it's even close. Trying to support 1.6, 1.7, and working towards 1.8,
> there's nothing left for working on master.
>
> If we wanted to do a quick 2.0 release and a Java 7 1.8 release, we can
> fork a 2.0 from 1.8 for JDK 8.
>
> My main concern with this suggestion, though, is the need to continue to
> support 4x branches. 1.7, 1.8, 2.0, and whatever master becomes (probably
> 3.0). I think it'll spread us far too thin (I think we're already too
> thin), and I don't think we can afford to drop 1.7, like we can for 1.6,
> because 1.8 hasn't been "in the wild" long enough yet, and we should
> continue to support 1.7.
>
> On Thu, Aug 18, 2016 at 6:50 PM Sean Busbey <bu...@cloudera.com> wrote:
>
> > I'm all for moving us towards java 8+ only, but I'm still -1 on
> > dropping java 7 in a minor release. Plenty of folks still run Java 7
> > in production. I'm sure a non-zero number of them will want to update
> > versions and a major version is how we communicate that level of
> > expected disruption.
> >
> > How about we get 1.8 out the door with Java 7 + Java 8, then try to
> > get master out the door with Java 8 as the minimum version? What's the
> > blocker on a release from master now?
> >
> > On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org>
> wrote:
> > > We need to make sure this release works with Java 8 anyway... but this
> > > change would tighten things up a bit, so we don't have to worry about
> > > supporting Java 7. It narrows our testing and allows us to focus on
> just
> > > the non-EOL, modern Java versions that we should be realistically
> > expecting
> > > users of Accumulo 1.8 to be using anyway.
> > >
> > > On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com>
> wrote:
> > >
> > >> Err, I am not a big fan of making this change after two rc's and all
> of
> > >> the testing I've been babysitting this week.
> > >>
> > >> I have no problem with you spinning a 2.0 which is 99% similar to 1.8
> > >> with whatever else you'd like to do (in fact, I'd encourage anyone to
> > >> step up and drive 2.0 to release).
> > >>
> > >> Sean Busbey wrote:
> > >> > Why don't we just make the 1.8 branch 2.0 then? I really don't want
> to
> > >> > drop support for JDKs on non-major releases; it's super disruptive.
> > >> >
> > >> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
> > >> wrote:
> > >> >> I know we've talked about this before, but I kind of want to just
> use
> > >> Java
> > >> >> 8 for Accumulo 1.8. It'd help clean up some things in the build
> (can
> > >> make
> > >> >> use of newer versions of build plugins, and make it easier for new
> > >> >> development against the latest release).
> > >> >>
> > >> >> I just don't know how reasonable it is to keep making new,
> non-bugfix
> > >> >> releases on EOL JDKs (even though I may have previously argued that
> > >> it'd be
> > >> >> safer to just wait until a major version bump).
> > >> >
> > >> >
> > >> >
> > >>
> >
> >
> >
> > --
> > busbey
> >
>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

Oh, master is in a terrible state (test instabilities). I wouldn't think
it's even close. Trying to support 1.6, 1.7, and working towards 1.8,
there's nothing left for working on master.

If we wanted to do a quick 2.0 release and a Java 7 1.8 release, we can
fork a 2.0 from 1.8 for JDK 8.

My main concern with this suggestion, though, is the need to continue to
support 4x branches. 1.7, 1.8, 2.0, and whatever master becomes (probably
3.0). I think it'll spread us far too thin (I think we're already too
thin), and I don't think we can afford to drop 1.7, like we can for 1.6,
because 1.8 hasn't been "in the wild" long enough yet, and we should
continue to support 1.7.

On Thu, Aug 18, 2016 at 6:50 PM Sean Busbey <bu...@cloudera.com> wrote:

> I'm all for moving us towards java 8+ only, but I'm still -1 on
> dropping java 7 in a minor release. Plenty of folks still run Java 7
> in production. I'm sure a non-zero number of them will want to update
> versions and a major version is how we communicate that level of
> expected disruption.
>
> How about we get 1.8 out the door with Java 7 + Java 8, then try to
> get master out the door with Java 8 as the minimum version? What's the
> blocker on a release from master now?
>
> On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org> wrote:
> > We need to make sure this release works with Java 8 anyway... but this
> > change would tighten things up a bit, so we don't have to worry about
> > supporting Java 7. It narrows our testing and allows us to focus on just
> > the non-EOL, modern Java versions that we should be realistically
> expecting
> > users of Accumulo 1.8 to be using anyway.
> >
> > On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com> wrote:
> >
> >> Err, I am not a big fan of making this change after two rc's and all of
> >> the testing I've been babysitting this week.
> >>
> >> I have no problem with you spinning a 2.0 which is 99% similar to 1.8
> >> with whatever else you'd like to do (in fact, I'd encourage anyone to
> >> step up and drive 2.0 to release).
> >>
> >> Sean Busbey wrote:
> >> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> >> > drop support for JDKs on non-major releases; it's super disruptive.
> >> >
> >> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
> >> wrote:
> >> >> I know we've talked about this before, but I kind of want to just use
> >> Java
> >> >> 8 for Accumulo 1.8. It'd help clean up some things in the build (can
> >> make
> >> >> use of newer versions of build plugins, and make it easier for new
> >> >> development against the latest release).
> >> >>
> >> >> I just don't know how reasonable it is to keep making new, non-bugfix
> >> >> releases on EOL JDKs (even though I may have previously argued that
> >> it'd be
> >> >> safer to just wait until a major version bump).
> >> >
> >> >
> >> >
> >>
>
>
>
> --
> busbey
>

Re: [DISCUSS] Java 8

[Sean Busbey <bu...@cloudera.com>]

I'm all for moving us towards java 8+ only, but I'm still -1 on
dropping java 7 in a minor release. Plenty of folks still run Java 7
in production. I'm sure a non-zero number of them will want to update
versions and a major version is how we communicate that level of
expected disruption.

How about we get 1.8 out the door with Java 7 + Java 8, then try to
get master out the door with Java 8 as the minimum version? What's the
blocker on a release from master now?

On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ct...@apache.org> wrote:
> We need to make sure this release works with Java 8 anyway... but this
> change would tighten things up a bit, so we don't have to worry about
> supporting Java 7. It narrows our testing and allows us to focus on just
> the non-EOL, modern Java versions that we should be realistically expecting
> users of Accumulo 1.8 to be using anyway.
>
> On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com> wrote:
>
>> Err, I am not a big fan of making this change after two rc's and all of
>> the testing I've been babysitting this week.
>>
>> I have no problem with you spinning a 2.0 which is 99% similar to 1.8
>> with whatever else you'd like to do (in fact, I'd encourage anyone to
>> step up and drive 2.0 to release).
>>
>> Sean Busbey wrote:
>> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
>> > drop support for JDKs on non-major releases; it's super disruptive.
>> >
>> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
>> wrote:
>> >> I know we've talked about this before, but I kind of want to just use
>> Java
>> >> 8 for Accumulo 1.8. It'd help clean up some things in the build (can
>> make
>> >> use of newer versions of build plugins, and make it easier for new
>> >> development against the latest release).
>> >>
>> >> I just don't know how reasonable it is to keep making new, non-bugfix
>> >> releases on EOL JDKs (even though I may have previously argued that
>> it'd be
>> >> safer to just wait until a major version bump).
>> >
>> >
>> >
>>



-- 
busbey

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

We need to make sure this release works with Java 8 anyway... but this
change would tighten things up a bit, so we don't have to worry about
supporting Java 7. It narrows our testing and allows us to focus on just
the non-EOL, modern Java versions that we should be realistically expecting
users of Accumulo 1.8 to be using anyway.

On Thu, Aug 18, 2016 at 6:37 PM Josh Elser <jo...@gmail.com> wrote:

> Err, I am not a big fan of making this change after two rc's and all of
> the testing I've been babysitting this week.
>
> I have no problem with you spinning a 2.0 which is 99% similar to 1.8
> with whatever else you'd like to do (in fact, I'd encourage anyone to
> step up and drive 2.0 to release).
>
> Sean Busbey wrote:
> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> > drop support for JDKs on non-major releases; it's super disruptive.
> >
> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>
> wrote:
> >> I know we've talked about this before, but I kind of want to just use
> Java
> >> 8 for Accumulo 1.8. It'd help clean up some things in the build (can
> make
> >> use of newer versions of build plugins, and make it easier for new
> >> development against the latest release).
> >>
> >> I just don't know how reasonable it is to keep making new, non-bugfix
> >> releases on EOL JDKs (even though I may have previously argued that
> it'd be
> >> safer to just wait until a major version bump).
> >
> >
> >
>

Re: [DISCUSS] Java 8

[Josh Elser <jo...@gmail.com>]

Err, I am not a big fan of making this change after two rc's and all of 
the testing I've been babysitting this week.

I have no problem with you spinning a 2.0 which is 99% similar to 1.8 
with whatever else you'd like to do (in fact, I'd encourage anyone to 
step up and drive 2.0 to release).

Sean Busbey wrote:
> Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> drop support for JDKs on non-major releases; it's super disruptive.
>
> On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ct...@apache.org>  wrote:
>> I know we've talked about this before, but I kind of want to just use Java
>> 8 for Accumulo 1.8. It'd help clean up some things in the build (can make
>> use of newer versions of build plugins, and make it easier for new
>> development against the latest release).
>>
>> I just don't know how reasonable it is to keep making new, non-bugfix
>> releases on EOL JDKs (even though I may have previously argued that it'd be
>> safer to just wait until a major version bump).
>
>
>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

Russ, the master branch would be relabeled 3.0. It's not compatible. We're
just determining what to call this release and its minimum dependencies. It
wouldn't change its contents.

On Thu, Aug 18, 2016 at 6:39 PM Russ Weeks <rw...@newbrightidea.com> wrote:

> I was under the impression that there were a few changes in 2.0 that (a)
> break semver and (b) are not quite ready to go? Because any such changes
> would have to wait for 3.0 wouldn't they? Otherwise 2.1 (say) would not be
> backwards-compatible with 2.0?
>
> On Thu, Aug 18, 2016 at 2:28 PM Sean Busbey <bu...@cloudera.com> wrote:
>
> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> > drop support for JDKs on non-major releases; it's super disruptive.
> >
> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org>
> wrote:
> > > I know we've talked about this before, but I kind of want to just use
> > Java
> > > 8 for Accumulo 1.8. It'd help clean up some things in the build (can
> make
> > > use of newer versions of build plugins, and make it easier for new
> > > development against the latest release).
> > >
> > > I just don't know how reasonable it is to keep making new, non-bugfix
> > > releases on EOL JDKs (even though I may have previously argued that
> it'd
> > be
> > > safer to just wait until a major version bump).
> >
> >
> >
> > --
> > busbey
> >
>

Re: [DISCUSS] Java 8

[Russ Weeks <rw...@newbrightidea.com>]

I was under the impression that there were a few changes in 2.0 that (a)
break semver and (b) are not quite ready to go? Because any such changes
would have to wait for 3.0 wouldn't they? Otherwise 2.1 (say) would not be
backwards-compatible with 2.0?

On Thu, Aug 18, 2016 at 2:28 PM Sean Busbey <bu...@cloudera.com> wrote:

> Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> drop support for JDKs on non-major releases; it's super disruptive.
>
> On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org> wrote:
> > I know we've talked about this before, but I kind of want to just use
> Java
> > 8 for Accumulo 1.8. It'd help clean up some things in the build (can make
> > use of newer versions of build plugins, and make it easier for new
> > development against the latest release).
> >
> > I just don't know how reasonable it is to keep making new, non-bugfix
> > releases on EOL JDKs (even though I may have previously argued that it'd
> be
> > safer to just wait until a major version bump).
>
>
>
> --
> busbey
>

Re: [DISCUSS] Java 8

[Sean Busbey <bu...@cloudera.com>]

we could also take the major version to do a pass of dependency updates.

On Thu, Aug 18, 2016 at 5:04 PM, Christopher <ct...@apache.org> wrote:
> Yeah, this discussion presumes the current vote fails. Also, it means we
> wouldn't really be dropping any deprecated stuffs from 1.* until at least
> 3.0.0. I think some folks might be happy about that. I'm certainly not
> going to push for removing anything this late in the game. This would just
> be like a minor release, but with new JDK requirements and named like a
> major release. The 1.8 branch is also building on Hadoop 2.6.4 by default,
> so it might also be best to document that we recommend using at least that
> (though not certain it's strictly required... earlier versions are just not
> well-tested).
>
> On Thu, Aug 18, 2016 at 5:57 PM Michael Wall <mj...@gmail.com> wrote:
>
>> I am good with requiring Java 8 and moving to 2.0 for the release.  Doesn't
>> look like the vote for 1.8.0 is going to pass, which is good.  That gives
>> us a little more time to discuss this.  We will have to redo all the
>> testing, which is fine too.
>>
>> On Thu, Aug 18, 2016 at 5:55 PM, Christopher <ct...@apache.org> wrote:
>>
>> > That's fine with me. I think people might expect a bigger jump with a
>> major
>> > version change like that, but it's not a big deal. The good stuffs I was
>> > hoping to get into a 2.0 will just happen at 3.0 instead.
>> >
>> > On Thu, Aug 18, 2016 at 5:28 PM Sean Busbey <bu...@cloudera.com> wrote:
>> >
>> > > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
>> > > drop support for JDKs on non-major releases; it's super disruptive.
>> > >
>> > > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org>
>> > wrote:
>> > > > I know we've talked about this before, but I kind of want to just use
>> > > Java
>> > > > 8 for Accumulo 1.8. It'd help clean up some things in the build (can
>> > make
>> > > > use of newer versions of build plugins, and make it easier for new
>> > > > development against the latest release).
>> > > >
>> > > > I just don't know how reasonable it is to keep making new, non-bugfix
>> > > > releases on EOL JDKs (even though I may have previously argued that
>> > it'd
>> > > be
>> > > > safer to just wait until a major version bump).
>> > >
>> > >
>> > >
>> > > --
>> > > busbey
>> > >
>> >
>>



-- 
busbey

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

Yeah, this discussion presumes the current vote fails. Also, it means we
wouldn't really be dropping any deprecated stuffs from 1.* until at least
3.0.0. I think some folks might be happy about that. I'm certainly not
going to push for removing anything this late in the game. This would just
be like a minor release, but with new JDK requirements and named like a
major release. The 1.8 branch is also building on Hadoop 2.6.4 by default,
so it might also be best to document that we recommend using at least that
(though not certain it's strictly required... earlier versions are just not
well-tested).

On Thu, Aug 18, 2016 at 5:57 PM Michael Wall <mj...@gmail.com> wrote:

> I am good with requiring Java 8 and moving to 2.0 for the release.  Doesn't
> look like the vote for 1.8.0 is going to pass, which is good.  That gives
> us a little more time to discuss this.  We will have to redo all the
> testing, which is fine too.
>
> On Thu, Aug 18, 2016 at 5:55 PM, Christopher <ct...@apache.org> wrote:
>
> > That's fine with me. I think people might expect a bigger jump with a
> major
> > version change like that, but it's not a big deal. The good stuffs I was
> > hoping to get into a 2.0 will just happen at 3.0 instead.
> >
> > On Thu, Aug 18, 2016 at 5:28 PM Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> > > drop support for JDKs on non-major releases; it's super disruptive.
> > >
> > > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org>
> > wrote:
> > > > I know we've talked about this before, but I kind of want to just use
> > > Java
> > > > 8 for Accumulo 1.8. It'd help clean up some things in the build (can
> > make
> > > > use of newer versions of build plugins, and make it easier for new
> > > > development against the latest release).
> > > >
> > > > I just don't know how reasonable it is to keep making new, non-bugfix
> > > > releases on EOL JDKs (even though I may have previously argued that
> > it'd
> > > be
> > > > safer to just wait until a major version bump).
> > >
> > >
> > >
> > > --
> > > busbey
> > >
> >
>

Re: [DISCUSS] Java 8

[Michael Wall <mj...@gmail.com>]

I am good with requiring Java 8 and moving to 2.0 for the release.  Doesn't
look like the vote for 1.8.0 is going to pass, which is good.  That gives
us a little more time to discuss this.  We will have to redo all the
testing, which is fine too.

On Thu, Aug 18, 2016 at 5:55 PM, Christopher <ct...@apache.org> wrote:

> That's fine with me. I think people might expect a bigger jump with a major
> version change like that, but it's not a big deal. The good stuffs I was
> hoping to get into a 2.0 will just happen at 3.0 instead.
>
> On Thu, Aug 18, 2016 at 5:28 PM Sean Busbey <bu...@cloudera.com> wrote:
>
> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> > drop support for JDKs on non-major releases; it's super disruptive.
> >
> > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org>
> wrote:
> > > I know we've talked about this before, but I kind of want to just use
> > Java
> > > 8 for Accumulo 1.8. It'd help clean up some things in the build (can
> make
> > > use of newer versions of build plugins, and make it easier for new
> > > development against the latest release).
> > >
> > > I just don't know how reasonable it is to keep making new, non-bugfix
> > > releases on EOL JDKs (even though I may have previously argued that
> it'd
> > be
> > > safer to just wait until a major version bump).
> >
> >
> >
> > --
> > busbey
> >
>

Re: [DISCUSS] Java 8

[Christopher <ct...@apache.org>]

That's fine with me. I think people might expect a bigger jump with a major
version change like that, but it's not a big deal. The good stuffs I was
hoping to get into a 2.0 will just happen at 3.0 instead.

On Thu, Aug 18, 2016 at 5:28 PM Sean Busbey <bu...@cloudera.com> wrote:

> Why don't we just make the 1.8 branch 2.0 then? I really don't want to
> drop support for JDKs on non-major releases; it's super disruptive.
>
> On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org> wrote:
> > I know we've talked about this before, but I kind of want to just use
> Java
> > 8 for Accumulo 1.8. It'd help clean up some things in the build (can make
> > use of newer versions of build plugins, and make it easier for new
> > development against the latest release).
> >
> > I just don't know how reasonable it is to keep making new, non-bugfix
> > releases on EOL JDKs (even though I may have previously argued that it'd
> be
> > safer to just wait until a major version bump).
>
>
>
> --
> busbey
>

Re: [DISCUSS] Java 8

[Sean Busbey <bu...@cloudera.com>]

Why don't we just make the 1.8 branch 2.0 then? I really don't want to
drop support for JDKs on non-major releases; it's super disruptive.

On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ct...@apache.org> wrote:
> I know we've talked about this before, but I kind of want to just use Java
> 8 for Accumulo 1.8. It'd help clean up some things in the build (can make
> use of newer versions of build plugins, and make it easier for new
> development against the latest release).
>
> I just don't know how reasonable it is to keep making new, non-bugfix
> releases on EOL JDKs (even though I may have previously argued that it'd be
> safer to just wait until a major version bump).



-- 
busbey