hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: [DISCUSS] Dependency compatibility
Date Wed, 11 Mar 2015 21:49:31 GMT
>
> 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
>

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