Thanks boss. I figured you'd have my back :) On May 5, 2016 9:43 PM, "Christopher" <ctubb...@apache.org> wrote:
> Already pushed. Initially forgot about modernizer, but I'm working through > it now. > > On Thu, May 5, 2016 at 7:25 PM Josh Elser <josh.el...@gmail.com> wrote: > > > Sounds good! > > > > I had tried to switch master to jdk8 as well, but ran into modernizer > > plugin issues. I've since been on a call, so I haven't been able to push > > that update. I'll get to it when I can, but perhaps someone has beaten > > me to it already. > > > > Christopher wrote: > > > Okay, so if we're okay treating the master branch as a 2.0 development > > > branch, then I'm going to go ahead and start focusing on some 2.0 > tickets > > > that may involve refactoring which have breaking changes that I've been > > > reluctant to do before without an explicit 2.0 development branch. Of > > > course, none of this says we have to stop development on 1.x stuffs, or > > > says anything about when we'll release a 2.0, but it'd be nice to have > a > > > place to start putting in stuff for an eventual 2.0. > > > > > > On Thu, May 5, 2016 at 11:07 AM Josh Elser<josh.el...@gmail.com> > wrote: > > > > > >> Ok, looks to me that we are in agreement now and don't need a vote. > > >> > > >> I will create a 1.8 branch today (updating Jenkins appropriately) so > we > > >> can get master in a state that would be ready for the changes in 4177. > > >> > > >> Keith Turner wrote: > > >>> On Tue, May 3, 2016 at 4:54 PM, Christopher<ctubb...@apache.org> > > wrote: > > >>> > > >>>> I think I'd prefer leaving 1.8 as it stands, with the expectation to > > >> have a > > >>>> release line of 1.8 which only requires Java 7. > > >>>> > > >>> +1 > > >>> > > >>> I can not see any reason to switch to JDK8 before releasing 1.8... > > >> assuming > > >>> thats going to happen soonish > > >>> > > >>> > > >>>> We can create a 2.0 branch, which bumps the Java version, and can > > accept > > >>>> changes which require Java 8 or API-breaking changes (as per semver) > > for > > >>>> the next major release line after 1.8. > > >>>> > > >>>> That would put us on a solid roadmap for 2.0 without disrupting 1.8 > > >>>> development, which is probably already nearing release readiness. > > >>>> > > >>>> On Tue, May 3, 2016 at 4:33 PM Josh Elser<josh.el...@gmail.com> > > wrote: > > >>>> > > >>>>> Gotcha. Thanks for clarifying, Mike -- I'm inclined to agree with > > you. > > >> I > > >>>>> can't think of a reason why we would upgrade to Java8 and not make > > use > > >>>>> of it in some way (publicly or privately). > > >>>>> > > >>>>> That being said, I don't think I see consensus. How about we > regroup > > in > > >>>>> the form of a vote? (normal semver rules are an invariant -- no > > changes > > >>>>> to our public API compatibility rules are implied by the below) > > >>>>> > > >>>>> * Call the current 1.8.0-SNAPSHOT (master) "2.0.0-SNAPSHOT" and > move > > to > > >>>>> jdk8 > > >>>>> * Branch 1.8, make master 2.0.0-SNAPSHOT. 1.8 stays jdk7, 2.0 goes > > jdk8 > > >>>>> > > >>>>> Please chime in if I missed another option or am calling discussion > > too > > >>>>> soon. It just seems like we might have veered off-track and I don't > > >> want > > >>>>> this to fall to the wayside (again) without decision. > > >>>>> > > >>>>> Mike Drob wrote: > > >>>>>> If our code ends up using java 8 bytecode in any classes required > > by a > > >>>>>> consumer, then I think they will get compilation (linking?) > errors, > > >>>>>> regardless of java 8 types in our methods signatures. > > >>>>>> > > >>>>>> On Tue, May 3, 2016 at 3:09 PM, Josh Elser<josh.el...@gmail.com> > > >>>> wrote: > > >>>>>>> That's a new assertion ("we can't actually use Java 8 features > util > > >>>>>>> Accumulo-2"), isn't it? We could use new Java 8 features > internally > > >>>>> which > > >>>>>>> would require a minimum of Java 8 and not affect the public API. > > >> These > > >>>>> are > > >>>>>>> related, not mutally exclusive, IMO. > > >>>>>>> > > >>>>>>> To Shawn's point: introducing Java 8 types/APIs was exactly the > > point > > >>>> -- > > >>>>>>> we got here from ACCUMULO-4177 which does exactly that. > > >>>>>>> > > >>>>>>> > > >>>>>>> Mike Drob wrote: > > >>>>>>> > > >>>>>>>> I agree with Shawn's implied statement -- why bother dropping > > Java 7 > > >>>> in > > >>>>>>>> any > > >>>>>>>> Accumulo 1.x if we can't actually make use of Java 8 > > features.until > > >>>>>>>> Accumulo 2.0 > > >>>>>>>> > > >>>>>>>> On Tue, May 3, 2016 at 1:29 PM, Christopher<ctubb...@apache.org > > > > >>>>> wrote: > > >>>>>>>> Right, these are competing and mutually exclusive goals, so we > > need > > >>>> to > > >>>>>>>>> decide which is a priority and on what timeline we should > > >> transition > > >>>>> to > > >>>>>>>>> Java 8 to support those goals. > > >>>>>>>>> > > >>>>>>>>> On Tue, May 3, 2016 at 9:16 AM Shawn Walker< > > >>>> accum...@shawn-walker.net > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> I'm not sure that guaranteeing build-ability under Java 7 would > > >>>>> address > > >>>>>>>>> the > > >>>>>>>>> > > >>>>>>>>>> issue that raised this discussion: We (might) want to add a > > >>>>> dependency > > >>>>>>>>>> which requires Java 8. Or, following Keith's comment, we > might > > >>>> wish > > >>>>> to > > >>>>>>>>>> introduce Java 8 types (e.g. CompletableFuture<T>) into > > Accumulo's > > >>>>>>>>>> > > >>>>>>>>> "public" > > >>>>>>>>> > > >>>>>>>>>> API. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Mon, May 2, 2016 at 6:42 PM, Christopher< > ctubb...@apache.org > > > > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> I don't feel strongly about this, but I was kind of thinking > > that > > >>>>> we'd > > >>>>>>>>>> bump > > >>>>>>>>>> > > >>>>>>>>>>> to Java 8 dependency (opportunistically) when we were ready > to > > >>>>> develop > > >>>>>>>>>> a > > >>>>>>>>>> 2.0 version. But, I'm not opposed to doing it on the 1.8 > branch. > > >>>>>>>>>>> On Mon, May 2, 2016 at 2:50 PM William Slacum< > > wsla...@gmail.com> > > >>>>>>>>>>> > > >>>>>>>>>> wrote: > > >>>>>>>>>> So my point about versioning WRT to the Java runtime is more > > about > > >>>>>>>>>>> how > > >>>>>>>>>> there are incompatibilities within the granularity of Java > > >> versions > > >>>>>>>>>>> we > > >>>>>>>>>> talk > > >>>>>>>>>>>> about (I'm specifically referencing a Kerberos > incompatibility > > >>>>> within > > >>>>>>>>>>>> versions of Java 7), so I think that just blanket saying "We > > >>>>> support > > >>>>>>>>>>> Java X > > >>>>>>>>>>> > > >>>>>>>>>>>> or Y" really isn't enough. I personally feel some kind of > > >> version > > >>>>>>>>>>> bump > > >>>>>>>>>> is > > >>>>>>>>>> > > >>>>>>>>>>> nice to say that something has changed, but until the public > > API > > >>>>>>>>>>> starts > > >>>>>>>>>> exposing Java 8 features, it's a total cop out to say, "Here's > > all > > >>>>>>>>>>> these > > >>>>>>>>>>> bug fixes and some new features, oh by the way upgrade your > > >>>>>>>>>>> infrastructure > > >>>>>>>>>>> > > >>>>>>>>>>>> because we decided to use a new Java version for an optional > > >>>>>>>>>>>> > > >>>>>>>>>>> feature". > > >>>>>>>>>> The best parallel I can think of is in Scala, where there's no > > >>>> binary > > >>>>>>>>>>>> compatibility between minor versions (ie, 2.10, 2.11,etc), > so > > >>>>> there's > > >>>>>>>>>>>> generally an extra qualifier on libraries marking the scala > > >>>>>>>>>>>> > > >>>>>>>>>>> compability > > >>>>>>>>>> level. Would we ever want to have accumulo-server-1.7-j[7|8] > > >>>> styled > > >>>>>>>>>>>> artifacts to signal some general JRE compatibility? It's a > > total > > >>>>>>>>>>>> > > >>>>>>>>>>> mess, > > >>>>>>>>>> but > > >>>>>>>>>>>> I haven't seen a better solution. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Another idea is we could potentially have some guarantee for > > >> Java > > >>>>> 7, > > >>>>>>>>>>> such > > >>>>>>>>>>> as making sure we can build a distribution using Java 7, but > > only > > >>>>>>>>>>>> distribute Java 8 artifacts by default? > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Mon, May 2, 2016 at 2:30 PM, Josh Elser< > > josh.el...@gmail.com > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> Sean Busbey wrote: > > >>>>>>>>>>>>> On Mon, May 2, 2016 at 8:55 AM, Josh Elser< > > >> josh.el...@gmail.com > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> Thanks for the input, Sean. > > >>>>>>>>>>>>>>>> Playing devil's advocate: we didn't have a major > > version > > >>>>> bump > > >>>>>>>>>>>>>>> when > > >>>>>>>>>>> we > > >>>>>>>>>>>>> dropped JDK6 support (in Accumulo-1.7.0). Oracle has > > EOL'ed > > >>>>>>>>>>>>>>> java 7 > > >>>>>>>>>>> back in > > >>>>>>>>>>>>>>>> April 2015. Was the 6->7 upgrade different than a > > 7->8 > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> upgrade? > > >>>>>>>>>> On Mon, May 2, 2016 at 10:31 AM, Keith Turner< > ke...@deenlo.com> > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>> On Mon, May 2, 2016 at 1:54 AM, Sean Busbey< > > >>>>>>>>>>>>>>> bus...@cloudera.com > > >>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>> If we drop jdk7 support, I would strongly prefer a > > major > > >>>>>>>>>>>>>>>>> version > > >>>>>>>>>>> bump. > > >>>>>>>>>>>>>>>> Whats the rationale for binding a bump to Accumulo > > 2.0 > > >>>> with > > >>>>> a > > >>>>>>>>>>>>>>> bump > > >>>>>>>>>>> in > > >>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>> JDK version? > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> The decision to drop JDK6 support happened in > latemarch / > > >>>>>>>>>>>>> earlyApril > > >>>>>>>>>>> 2014[1], long before any of our discussions or decisions on > > >>>>>>>>>>>>> semver. > > >>>>>>>>>> AFAICT it didn't get discussed again, presumably because by > the > > >>>>>>>>>>>>> time > > >>>>>>>>>> we got to 1.7.0 RCs it was too far in the past. > > >>>>>>>>>>>>>> Thanks for the correction, Sean. I hadn't dug around > closely > > >>>>>>>>>>>> enough. > > > > > >