> On Nov 11, 2015, at 12:13 PM, Vinod Vavilapalli <vino...@hortonworks.com>
> wrote:
>
> — HDFS-6200 Create a separate jar for hdfs-client: Compatible improvement
> - no dimension of alpha/betaness here.
IMO: this feels like a massive break in backwards compatibility. Anyone
who is looking for specific methods in specific jars are going to have a bad
time. Also, it seems as though every week a new issue crops up that is related
to this change. Is Slider still having problems with it? The reasoning “well,
the pom sets the dependencies so it’s ok” feels like an *extremely weak* reason
this wasn’t marked incompatible— it basically makes the assumption that
everyone recompiles for every minor release.
> — Compatibility tools to catch backwards, forwards compatibility issues at
> patch submission, release times. Some of it is captured at YARN-3292. This
> also involves resurrecting jdiff (HADOOP-11776/YARN-3426/MAPREDUCE-6310)
> and/or investing in new tools.
There has been talk in the past about adding Java ACC support to Yetus.
> Thoughts?
I’d rather see efforts on 3.x than another disastrous 2.x release. The
track record is not good. At least a new major will signify that danger looms
ahead. We’re already treating 2.x minor releases as effectively major (see the
list of incompatible JIRAs) so what different does it make if we do 2.x vs. 3.x
anyway?
>
> Thanks
> +Vinod
> PS:As you may have noted above, this time around, I want to do something that
> we’ve always wanted to do, but never explicitly did. I’m calling out
> readiness of each feature as they stand today so we can inform our users
> better of what they can start relying on in production clusters.
… except some of these changes are so deep reaching that even if you
don’t use the feature, you’re still impacted by it ...
