+1 I think the pros of skipping 1.8 have already been summed up pretty well by others, and I agree with those arguments.
> On Aug 23, 2016, at 12:44 AM, Ed Coleman <[email protected]> wrote: > > +1 > > Sending anyway - I don't care that Christopher can type faster (and probably > more coherently) and sorry if this is long, trying to layout my thoughts. > > tl;dr We would likely skip any 1.8 versions and jump to 2.x. Eol-ing 1.7.x > "soon" would likely force us to take additional risk and move faster than we > naturally would. Keeping 1.7.x, 1.8.x, 2.x and an experimental 3.x would be > an increase in developer burden, especially since we should keep any 1.8 > versions current for some time. Keeping the number of active branches that > are actively used by customers to a minimum is more desirable to me than > having a 1.8 version and 2.0 version that are essentially the same code base, > regardless of the Java version required. > > Upgrading a running system is not trivial and we do not move very quickly. > The way that I envision versions (if this vote passes) would be along the > lines of: > > 1.6.6 - eol the 1.6 line > 1.7.x - the "production" branch for risk adverse, slow moving customers, with > critical bug fixes as necessary. > 1.8 - skip. > 2.0 - the improvements slated for 1.8, requires Java 8. Becomes the branch > for new features. > 3.0 - experimental with removal of deprecated features, incorporates the API > changes that Christopher has been working on, > > If 1.8 was released as is-ish and then 2.0 was released "soon" thereafter > with basically everything in 1.8, but requiring java 8, we would probably try > very hard to skip upgrading to the 1.8 version and go with 2.x when we are > ready. > > If the vote fails: > > We release 1.8, and 1.6.6 and 1.7.x were both eol'ed, we would probably still > try to skip 1.8 - again assuming that 1.8 and 2.0 are very close code base, > except for java 8 - but this would push us to the 1.8/2.0 changes earlier > than we naturally would. > > Other considerations: > > With Java 7, it is my understanding that there are other packages / maven > modules that we cannot use because they require Java 8 as a minimum version. > With a Java 8 / 2.x version we could begin to take use them. > > Moving from 1.6.x or 1.7.x to 1.8 / the proposed 2.0 represents the same > amount of risk so there seems little benefit of a 1.8 release at this time. > > We (Accumulo) can devote additional testing to 2.0 / java 8 - because we > would not need to test essentially the same features with 1.8 / Java 7. > > Java 8 has been available since Red Hat 6.6, released Oct 2014, so most > customers likely have Java 8 available if they are not running it already. > One sticking point was Hadoop and java 8 support which seems to have been > resolved around Oct 2015 > (https://issues.apache.org/jira/browse/HADOOP-11090). Java 7 was eol-ed by > Oracle April 2015, and Red-Hat support for openjdk7 is ending in 6/2018 - so > us requiring Java 8 for a 2.0 version does not (in my opinion) represent a > barrier to those that would move to a 2.0 version in the near future. > > The removal of deprecated code and the envisioned API changes will be > significant and will really require close scrutiny and a compelling reason to > change Adoption will likely be fairly slow. We need to be able to move > forward with these, while maintaining the existing code base, so an > experimental 3.0 branch seems logical, but would not be a basis for near term > releases (they would use 2.x as the baseline.) > > Keeping the number of active branches that are actively used by customers to > a minimum is more desirable to me than having a 1.8 version and 2.0 version > that are essentially the same code base, regardless of the Java version > required. > > With these considerations, I vote +1 to not release 1.8, instead release a > 2.0 version of that code base with the additional change of requiring Java 8. > > v/r > > Ed Coleman > > Josh wrote > > -----Original Message----- > From: Dylan Hutchison [mailto:[email protected]] > Sent: Monday, August 22, 2016 8:49 PM > To: Accumulo Dev List <[email protected]> > Subject: Re: [VOTE] Plan for next release > > -1, primarily with the spirit of "Release Early, Release Often > <https://incubator.apache.org/guides/graduation.html#releases>". Let's get > our changes out there, rather than wait another month to add in Java 8. My > vote is not religious, however, and it could change if someone argues for > some incredible difference Java 8 could make in a release *right now*. > > I don't see enough immediate benefit in releasing a Java 8 branch. Not much > Java 8 dependent has changed since introducing Java 8 into master. We can do > Java 8 development with master. > > I agree with Josh that the maintenance burden does not seem very different > with the proposed plan. Then again I have not been actively developing new > features recently; perhaps someone who is working on a grand change for 2.0 > could comment on how accelerated-release 2.0 would be helpful for development > on 3.0. > > On Mon, Aug 22, 2016 at 5:34 PM, Josh Elser <[email protected]> wrote: > >> Again, sorry for the spam from me. I should've just turned off my >> phone instead of trying to catch up while doing other things. >> >> It still seems to me that the predominant concern proposed here is an >> increased burden on maintenance. However, avoiding 1.8 and calling it >> 2.0 instead feels like kicking the can down the road to me. Let's me >> describe the scenario I see: >> >> Assume we drop 1.8 and do the reverts to make the current master >> branch 2.0.0-SNAPSHOT sans everything but the JDK8 change (as per >> Christopher's original VOTE msg). We will release from master (or some >> 2.0 branch) and then, I believe, the plan laid out states we would try >> to use the master branch for the primary development actions. The >> current API removals which are presently slated for 2.0.0 now land in >> 3.0.0-SNAPSHOT. I would assume that this means master would become >> 3.0.0-SNAPSHOT. However, the next release we'd be doing is likely a >> 2.1.0-SNAPSHOT (historically speaking). >> >> So, given the above, whether this vote passes with +1's or -1's, I >> don't see any change in what we actually have to support (just in the >> naming): >> either [1.6, 1.7, 1.8] with 2.0 on deck, or [1.6, 1.7, 2.0] with 2.1 >> on deck (and maybe 3.0?). As such, I think coming up with a plan to >> *enable* users to *safely* and *confidently* move off of older >> releases (specifically, EOL both 1.6 *and* 1.7, regardless of this >> vote) is the appropriate solution to a concern about increased maintenance >> burden. >> >> To play devil's advocate: I am also making the assumption that we >> would have a normal cadence of 2.x releases (as we have historically have >> done). >> This hasn't been explicitly stated, so I may be misinterpreting things. >> Please do correct me if I'm wrong. >> >> Josh Elser wrote: >> >>> Ok, I need to step back. I see that minJdk 8 was suggested but maybe >>> not using any new APIs for this proposed 2.0 release? This isn't 100% >>> clear to me at present. I will have to reread everything later tonight. >>> >>> >>> On Aug 22, 2016 18:49, "Josh Elser" <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> (sorry posting from phone) >>> >>> I missed the run jdk7 artifacts on jdk8 comment: I am not concerned >>> about this case (Oracle worries about it for me). I am worried about >>> jdk8 features being introduced in this hypothetical 2.0 which >>> preclude users from using jdk7 (for a primary reason of "I wanna us >>> new shiny APIs!" without concrete justification). >>> >>> Christopher has so previously shared his concerns with me about >>> obtaining jdk7 packages from the internet. I do not think these are >>> valid concerns to present as justification for the change. >>> >>> >>> On Aug 22, 2016 18:35, "Josh Elser" <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 2.0 is not released, so there is no burden. >>> >>> Why do we need to maintain 1.6 or 1.7 as active? Why not eol and >>> provide actual testing and migration strategies to actually >>> *deal* with the maintenance burden instead of pushing it onto >>> the users? >>> >>> I would counter your question about tagging but not releasing >>> with "why not fix the packaging issues from rc2 and just make >>> the release?" >>> >>> With the amount of chatter on this vote thread, I am also now >>> worried that calling this vote was premature. These are >>> discussions that should have been hashed out already.. >>> >>> >>> On Aug 22, 2016 18:23, <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I share your concerns and have proposed releasing a 1.8.0 >>> as-is, followed by a 2.0 with much the same artifacts plus >>> Java 8 source. In talking with Christopher about this >>> though, that means that the community would be supporting >>> 1.6 (until 1.6.6 is released), 1.7.x, 1.8.x, and 2.0.x. >>> Being on update 102, Java 8 seems pretty stable. Plus, you >>> can run your Java 7 binaries with the Java 8 JRE. >>> >>> Having said that, is there a reason that we can't tag 1.8.0 >>> but not release it and let other downstream providers create >>> their own supported release? >>> >>>> -----Original Message----- >>>> From: [email protected] <mailto:[email protected]> >>> [mailto:[email protected] <mailto:[email protected]>] >>> On Behalf Of >>>> Josh Elser >>>> Sent: Monday, August 22, 2016 6:17 PM >>>> To: [email protected] >>> <mailto:[email protected] >>> g> >>>> Subject: Re: [VOTE] Plan for next release >>>> >>>> Mike Wall asked if I could expand. I realized that my >>> objections were >>>> probably only in IRC with Christopher and didn't get >>> cross-posted. I had >>>> thought that they were already present in the discussion >>> thread. >>>> >>>> 1. 1.8.0 is practically released already as-is. I spent a >>> good chunk of the last >>>> week babysitting tests. This change feels no different >>> than someone shoe- >>>> horning in a big feature at the last minute. >>>> >>>> 2. I think this is a slap in the face to anyone that was >>> waiting on a 1.8.0 to be >>>> released as slap in the face. The release that was about >>> to happen now has >>>> an even longer cycle. >>>> >>>> 3. Assuming that min jdk 8 also implies use of jdk 8 only >>> features (as was >>>> mentioned), my experience with customer bases is that >>> people are not yet >>>> there. Often, these groups do have migration plans in >>> place, but I haven't >>>> seen one that has a quicker than one year turnaround. I >>> cannot back any of >>>> this up with fact, it is merely observations from my >>> day job. >>>> >>>> I do not find the provided reasons to make this last >>> minute change >>>> justification enough to do it. I am very much against it. >>>> >>>> On Aug 22, 2016 17:58, "Josh Elser" <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>>> -1 >>>>> >>>>> On Aug 22, 2016 17:22, "Christopher" >>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>>> After our lengthy (sorry for that) discussions about >>> Java 8, 1.8.0, >>>>>> and 2.0.0, I wanted to bring us to a vote, just so we >>> can have a >>>>>> concrete plan of action, without any ambiguity or >>> uncertainty. A vote >>>>>> is the best option available for resolving differences >>> of opinion >>>>>> about our upcoming release plans. >>>>>> >>>>>> The action to vote on is the following: >>>>>> >>>>>> (+1): Drop 1.8 branch, stabilize the master >>> branch, and release >>>>>> 2.0.0 from master >>>>>> >>>>>> If the vote fails to pass, the default action (which >>> is implied by a >>>>>> -1) is the following: >>>>>> >>>>>> (-1): Release 1.8.0, supporting a 1.8.x release >>> series; 2.0.0 and >>>>>> the master branch will be addressed at some >>> unspecified future time >>>>>> >>>>>> This is a majority vote regarding release plans, so we >>> can make >>>>>> progress on a reasonable release timeline. Specific >>> changes in a >>>>>> branch can still be veto'd while we work towards the >>> release, as >>>>>> normal, regardless of the outcome of this vote. >>>>>> >>>>>> Here's some main points to consider for this vote: >>>>>> >>>>>> * Everything in the 1.8 branch is included in the >>> Master branch. >>>>>> * Master branch requires Java 8. >>>>>> * Releasing from master will allow us to work from >>> master again for >>>>>> routine development, instead of reserving master for >>> unstable >>>>>> development (which is how it currently has been >>> treated). >>>>>> * Master branch aggressively removes deprecated >>> stuffs; I'm actively >>>>>> working on reverting these in master regardless of the >>> vote, because >>>>>> they introduced some destabilization. >>>>>> * The one deprecation removal which I intend to keep >>> in Master is the >>>>>> removal of the trace library (not the tracer server, >>> which will >>>>>> stay). We don't need the trace library, because we now >>> use HTrace. If >>>>>> people need the deprecated HTrace wrappers for their >>> own code in that >>>>>> trace library, they should still be able to use the >>> wrappers in the >>>>>> 1.7 version of accumulo-trace. They won't need it for >>> Accumulo, >>>>>> though, because Accumulo doesn't use it, not even in >>> the 1.7 branch. >>>>>> This would be added to the release notes if this vote >>> passes. >>>>>> * After reverting the deprecation removals, the master >>> branch is >>>>>> *very* similar to the 1.8 branch right now. It >>> contains only a few >>>>>> extra commits, mostly for Java 8-related cleanups and >>> README >>>>>> improvements. (git log origin/1.8..origin/master >>> --no-merges >>>>>> --oneline) >>>>>> * If this vote passes, it will be 100%, or nearly 100%, >>>>>> backwards-compatible with 1.7.x, just as 1.8 branch is >>> today. This is >>>>>> because there haven't been much changes in the master >>> branch which >>>>>> aren't coming from merges from 1.8. This will mean >>> that the entire >>>>>> 2.x line will be just as backwards-compatible as this >>> next release >>>>>> and there will be no significant deprecation removals >>> from [1.7.0, 3.0). >>>>>> >>>>>> This vote will end on Thu Aug 25 21:30:00 UTC 2016 >>> (Thu Aug 25 >>>>>> 17:30:00 EDT 2016 / Thu Aug 25 14:30:00 PDT 2016) >>>>>> >>>>> >>> >>> >>> >
