Branch 1.8, leave at JDK 7 Move master to 2.0.0-SNAPSHOT and: -> Move to JDK 8 -> Remove deprecated items -> Bump versions for dependencies (*Htrace issue)
Question: Could we release 1.8.0 and 2.0.0 around the same time such that 2.0.0 is equivalent to 1.8.0 except for the changes mentioned above? ----- Original Message ----- From: "Josh Elser" <[email protected]> To: [email protected] Sent: Tuesday, May 3, 2016 4:33:39 PM Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache) 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<[email protected]> 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<[email protected]> 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<[email protected]> >>>> 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<[email protected]> >>>>> 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<[email protected]> >>>>>> >>>>> 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<[email protected]> >>>>>>> >>>>>> wrote: >>>>>> Sean Busbey wrote: >>>>>>>> On Mon, May 2, 2016 at 8:55 AM, Josh Elser<[email protected]> >>>>>>>> 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<[email protected]> >>>>>>>> wrote: >>>>>>> On Mon, May 2, 2016 at 1:54 AM, Sean Busbey< >>>>>>>>>> [email protected] >>>>> 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. >>> >
