hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject [DISCUSS] Dependency compatibility
Date Wed, 11 Mar 2015 21:04:29 GMT
Over at https://issues.apache.org/jira/browse/HBASE-13149, there is some
discussion about changing the jackson version from 1.8 to 1.9 that is worth
bringing here because of the wider audience. The discussion is about
jackson version specific in this issue, but we should also consider future
changes to libs.

The question is, whether we can change the dep version of jackson from 1.8
to 1.9 in HBase-1.1. According to our guidelines, we said that we will not
do breaking changes to our deps in minor versions. From the analysis of
jackson compat attached at jira, it seems that jackson have some changes
breaking BC.

So, from a purist perspective, if we follow our guidelines literally, we
should not make this change. However, I think we should make that change in
1.1 (and make similar changes in the future as well), because:

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.

2. HBase is not at the maturity level for following the dependency compat
guide literally without reducing the dep footprint, better isolation of MR
/ Mini cluster out of hbase-server and possible participation from hadoop.
We cannot easily bump up the major version for these as well, since major
version implies other things.

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.

Let me know what you guys think.
Enis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message