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 <[email protected]> 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/ > <[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 > > > > > >
