hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Francke <lars.fran...@gmail.com>
Subject Re: Removal of deprecated features
Date Mon, 06 Apr 2015 11:54:01 GMT
Thanks Lars. Any other opinions, any more input?

If not I hope to have some time this week to work on these points:

* 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 (using JavaDoc and in the book)
* Clarify that all deprecations that were added in 2.x will be removed in
4.0.0 (using JavaDoc and in the book)
* Clarify the SemVer documentation with a different example

I'd rather not do unnecessary or unwanted work :)

Any (git) hints on how to figure out for which tag something was first
marked deprecated are welcome too...

On Fri, Apr 3, 2015 at 9:32 PM, Lars George <lars.george@gmail.com> wrote:

> 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