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]> 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]> 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]> 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]] On Behalf Of >> > Josh Elser >> > Sent: Monday, August 22, 2016 6:17 PM >> > To: [email protected] >> > 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]> wrote: >> > >> > > -1 >> > > >> > > On Aug 22, 2016 17:22, "Christopher" <[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) >> > >> >> > > >> >> >>
