hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars George <lars.geo...@gmail.com>
Subject Re: Removal of deprecated features
Date Fri, 03 Apr 2015 19:32:35 GMT
I am +1 , especially on tagging/marking the deprecations proper with a
version when it will be removed. Right now we have deprecated functions
(for good reason) that are still lingering around. We have JIRAs
deprecating features, but no follow up process to really remove them. There
are no scheduled JIRAs to track those. Having them marked with a drop
version will make it easy to do a clean sweep JIRA before a major release.

As for keeping cruft for the sake of slow changing user setups, I would
also go with the doubling up of keeping them, as in deprecated in two major
releases before removal. That should give plenty of time.

No?

Lars

On Tue, Mar 31, 2015 at 8:36 AM, Lars Francke <lars.francke@gmail.com>
wrote:

> Sean, thanks for your comments.
>
> On Tue, Mar 31, 2015 at 2:09 AM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > 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.
> >
>
> Ah...I see...well that could be too. I happily defer to native speakers in
> interpreting that sentence. Or obviously to the original discussion/intent.
> If what you say is the original intent that's fine too. Maybe we could then
> clarify the example and only remove things in 2.0.0 that were already
> deprecated pre-1.0.0.
>
>
> >
> > 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?
> >
>
> I want to remove them for even more selfish reasons: Limit confusion on my
> end (hoping that there's more people like me out there). I only get to play
> with HBase every so often so have to relearn bits and pieces every time.
> And it's confusing to tell why certain things are deprecated but still in
> use etc. Currently I'm working with a client on HBase and reviewing the
> second edition of LarsG's book and we've stumbled across quite a few things
> that cause confusion in both projects because the intent is not clear or
> because long deprecated features still linger around.
>
> There's also things like this <
> https://issues.apache.org/jira/browse/HBASE-13274> which get flushed out.
>
> So I'd say we should remove deprecated things mostly for the end user and
> for (new) contributors to the project.
>
>
> 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
>
>
> I see what you mean and maybe keeping deprecated things around an extra
> version is good for that. Keeping deprecated things for an unspecified time
> is more a disservice than removing them at clearly documented points in
> time in my opinion.
>
> My new proposal would thus be:
>
> * 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
> * Clarify that all deprecations that were added in 1.x will be removed in
> 3.0.0
> * Clarify that all deprecations that were added in 2.x will be removed in
> 4.0.0
> * Clarify the SemVer documentation with a different example
> * 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])
>
>
>
> >
> --
> > Sean
> > 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
> > > >
> > >
> >
>

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