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
advertised.
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<apurt...@apache.org>
wrote:
Anyone disagree with the point of view put forward by Josh and Sean?
