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 Thu, 18 Aug 2016 23:30:01 GMT
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