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/ <[email protected]> On Aug 18, 2016 7:13 PM, "Christopher" <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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<[email protected]> > > >> 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 > > >
