hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))
Date Thu, 23 Apr 2015 20:35:47 GMT
Enis Söztutar wrote:
> +1 to the proposal.
> The problem is that we have a very big API surface especially with the
> coprocessors included in the report. Even simple bug fixes can introduce
> protected or public methods to base classes, which makes patch releases
> very hard to maintain. I would not want to spend the effort to spend tons
> of time trying to make a patch not introduce new methods in order to
> backport. That effort can be spent elsewhere IMO.

Abso-friggin-lutely. Following bug-fix strictness is a _massive_ pain in 
the rear (been dealing with this over in Accumulo-landia and it sucks). 
IMO, the crux of what to consider here is finding the acceptable level 
to which HBase Devs want to hold themselves and how much knowledge is 
just expected of users.

Like you said, it is a lot of effort for what seems like ultimately very 
little effect on users. It will take constant effort by everyone landing 
patches in a bug-fix branch to not make the RM want to punch themself in 
the face.

> Looking at the report
> https://people.apache.org/~enis/1.0.0_1.0.1RC2_compat_report.html, nothing
> strikes me as "new functionality". Going from current 1.0.0 to 1.0.1RC2
> should actually be as you would expect from upgrading a patch release.
> Yes, adding new API in patch releases will make downgrading harder, but I
> think that is an acceptable tradeoff. We can document that if your
> application compiles (meaning that you are not using new API) with 1.0.0,
> then you can swap your jars in a binary compat manner.

Like you pointed out in the other thread, though, choosing to follow 
semver is for the user. Your proposed solution adds in extra complexity 
on users that would otherwise be as simple as flipping the version on 
their Maven/Ivy configuration. Like you say, they should still be able 
to do things with the new jars against the old cluster, but it is a 
sharp-corner users would need to be aware of that isn't semver as 

Really, I'm trying to play devil's advocate here. In the end, my only 
concern would be appropriate advertisement of what decision is made.

> Enis
> On Thu, Apr 23, 2015 at 10:03 AM, Andrew Purtell<apurtell@apache.org>
> wrote:
>> Anyone disagree with the point of view put forward by Josh and Sean?

View raw message