hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haohui Mai <ricet...@gmail.com>
Subject Re: [DISCUSS] Looking to a 2.8.0 release
Date Wed, 11 Nov 2015 22:15:44 GMT
bq.  it basically makes the assumption that everyone recompiles for
every minor release.

I don't think that the statement holds. HDFS-6200 keeps classes in the
same package. hdfs-client becomes a transitive dependency of the
original hdfs jar.

Applications continue to work without recompilation as the classes
will be in the same name and will be available in the classpath. They
have the option of switching to depending only on hdfs-client to
minimize the dependency when they are comfortable.

I'm not claiming that there are no bugs in HDFS-6200, but just like
other features we discover bugs and fix them continuously.


On Wed, Nov 11, 2015 at 12:43 PM, Allen Wittenauer <aw@altiscale.com> wrote:
>> On Nov 11, 2015, at 12:13 PM, Vinod Vavilapalli <vinodkv@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 ...

View raw message