accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Coleman" <d...@etcoleman.com>
Subject RE: [VOTE] Plan for next release
Date Tue, 23 Aug 2016 04:44:35 GMT
+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:dhutchis@cs.washington.edu] 
Sent: Monday, August 22, 2016 8:49 PM
To: Accumulo Dev List <dev@accumulo.apache.org>
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 <josh.elser@gmail.com> 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" <josh.elser@gmail.com 
>> <mailto:josh.elser@gmail.com>> 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" <josh.elser@gmail.com
>>     <mailto:josh.elser@gmail.com>> 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, <dlmarion@comcast.net
>>         <mailto:dlmarion@comcast.net>> 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: josh.elser@gmail.com <mailto:josh.elser@gmail.com>
>>             [mailto:josh.elser@gmail.com <mailto:josh.elser@gmail.com>]
>>             On Behalf Of
>>              > Josh Elser
>>              > Sent: Monday, August 22, 2016 6:17 PM
>>              > To: dev@accumulo.apache.org 
>> <mailto:dev@accumulo.apache.or
>> 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" <elserj@apache.org
>>             <mailto:elserj@apache.org>> wrote:
>>              >
>>              > > -1
>>              > >
>>              > > On Aug 22, 2016 17:22, "Christopher"
>>             <ctubbsii@apache.org <mailto:ctubbsii@apache.org>> 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)
>>              > >>
>>              > >
>>
>>
>>


Mime
View raw message