hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Removal of deprecated features
Date Tue, 31 Mar 2015 00:09:44 GMT
I thought "deprecated for a major version" meant that to be removed in e.g.
HBase 2.0.0 we had to have deprecated the API by HBase 1.0.0, that is to
say I thought we claimed a stronger stance than semver required specificly
for API compat. I can see the ambiguity though.

Are we removing deprecated things just for code cleanup, of because keeping
them around is limiting some other set of changes we want to make?

This ties back into discussions of how long we keep doing minor releases
once a newer major release happens. If we expect major releases to have a
good deal of overlap, then I'm less concerned about breaking old clients.
But if we expect people to go through a major release upgrade e.g. every 2
years in order to keep seeing updates, then I'd rather err on the side of
cruft if it makes downstream maintenance easier.

On Mar 30, 2015 6:53 PM, "Lars Francke" <lars.francke@gmail.com> wrote:

> I know this was discussed briefly last year[1] but I'd like to bring it up
> again.
> I'd like to remove a bunch of deprecated features. Now with Semantic
> Versioning this should be a bit simpler.
> I propose the following:
> * In the master branch (which will be released as 2.0.0 if I'm not
> mistaken) remove (or undeprecate if it turns out the functionality is
> actually still needed) all functionality that was marked deprecated prior
> to 1.0.0 or in any 1.x release
> * All new deprecations could mention a version when they are going to be
> removed, according to SemVer this should be the next major version (e.g.
> "This feature is scheduled to be removed in HBase 3.0.0"[2])
> Do you think that's reasonable? If so I'm happy to file JIRAs and go
> through the code to get started.
> I think this is also in line with what our docs state: "An API needs to
> deprecated for a major version before we will change/remove it. Example: A
> user using a newly deprecated api does not need to modify application code
> with hbase api calls until the next major version."
> Cheers,
> Lars
> [1] <
> http://search-hadoop.com/m/DHED4RCfea/deprecation&subj=Regarding+removal+of+deprecated+APIs
> >
> [2] Similar to how Guava handles this <
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Objects.ToStringHelper.html
> >

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