> > All of our current ref guide examples use the "hadoop jar" command: > > http://hbase.apache.org/book.html#hbase.mapreduce.classpath > > http://hbase.apache.org/book.html#_bundled_hbase_mapreduce_jobs > > They only rely on the hbase command to get things that need to be added to > hte hadop classpath. > > See 117.3. It seems, we are suggestion both formats. As Nick pointed out, this is a separate discussion though.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > How would this inconvenience users further? Barring the change in > version > > > numbers, it's the same upgrade they would be doing to move to what > we're > > > currently calling HBase 1.1. Since version numbers under semver signal > > what > > > we understand about our changeset, it's just us acknowledging that we > > broke > > > some kind of compatibility. A release note that calls out the Jackson > > > dependency as the cause for that compatibility breakage makes the > > > evaluation easy. > > > > > > > The problem is boils down to "major versions are cheap" kind of argument, > > which have > > been discussed in Hadoop context. I do not buy it, because a major > version > > upgrade implies > > (though do not have to be) a big change. I don't see why ever we would > want > > to bump > > our major version, where the said library only bumped their minor > version. > > Jackson could > > have went with 2.0 for those changes between 1.8 and 1.9. Why would we > want > > to > > promise more than what our dependencies promise? It is not realistic. > > > > > > But we _know_ that 1.8 -> 1.9 in jackson is not really a minor version in > the semver sense. we _know_ it's a breaking change. Their release notes > even call out breaking changes, so we know it isn't just a change in > internals. > > > -- > Sean >
