On Wed, Mar 11, 2015 at 4:04 PM, Enis Söztutar <e...@apache.org> wrote:
> > 1. Hadoop upgraded its version of jackson in 2.5, and HBase MR jobs fail > flat out without corresponding change in HBase (with Hadoop-2.5+). We do > not have any control over Hadoop or similar core dependencies. We cannot be > realistically expected to guarantee more than what they do. I would rather > do the change in 1.1 and not inconvenience the users, than not do the > change, and have to explain how to replace the jars in the docs. This > argument should be extended beyond the jackson dependency. > > It's worth noting that if users follow our ref guide (which says to use "hadoop jar"), then jobs don't fail. It's only when they attempt to launch jobs using "hbase com.example.MyDriver" that things fail. Additionally, if we stick to telling users that only the "hadoop jar" version is supported, we can rely on the application classpath support built into Hadoop 2.6+ to make it so jobs built on us get our dependency version and not the ones from Hadoop as it changes. > So, my proposal is: > - Commit HBASE-13149 to master and 1.1 > - Either change the dependency compat story for minor versions to false, > or add a footnote saying that there may be exceptions because of the > reasons listed above. > If we decide we need to do the jackson version bump, what about the possibility of moving the code in branch-1 to be version 2.0.0 (and making master 3.0.0). We could start the release process once the changes Andrew needs for Phoenix are in place and get it out the door. It would do a nice job of desensitizing us to major version increments and we'd be able to document it as a very safe major version upgrade since the only breakage is that dependency. We could then limit the HBase 1.y line to just 1.0.z and add a FAQ item if enough folks ask about why the sudden increment. I'm -1 on the idea of exceptions for our compatibility story. We already note that just because we can break something doesn't mean we will. That does a good job of pointing out that we recognize there's a cost. I really like the fact that we do dependency compat promises on minor versions. So long as we're making choices that constrain downstream (like java compiler versions or classpaths with third-party dependencies), that promise means that I can just pay the cost of relying on the same version HBase does and in exchange I have one less thing to worry about when evaluating the risk of keeping up with minor releases. -- Sean
