accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Marion <dmario...@gmail.com>
Subject Re: [DISCUSS] Java 8
Date Thu, 18 Aug 2016 23:23:07 GMT
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