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. ~Haohui On Wed, Nov 11, 2015 at 12:43 PM, Allen Wittenauer <a...@altiscale.com> wrote: > >> 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 ... > >
