> > 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. >
We have learned that the users do not read or follow documentation. And it is a regression if launching job using hbase command does not work. > > > > > 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. > I don't think this requires a major version bump. As I was mentioning in the other thread, HBase is not upgraded too frequently in production. Again, we do not want to inconvenience the user even further. > > 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. > Doing a major version just to update one dependency version is too much I think. > > 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. > We do not have to corner ourselves with the rules we have set. I can see how requiring JDK-8 or Hadoop-3 etc will justify major versions. But not a dependency library that users might be transitively depending on. If that is the case, the user is expected to deal with it. > > 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 >
