accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Java 8
Date Fri, 19 Aug 2016 20:16:01 GMT
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 <ctubbsii@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 <ctubbsii@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 <dmarion18@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/
>>> <2113920695.26610898.1462308522327.JavaMail.zimbra@comcast.net>
>>>
>>> On Aug 18, 2016 7:13 PM, "Christopher" <ctubbsii@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 <busbey@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 <ctubbsii@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 <josh.elser@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
>>> > >
>>> >
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message