You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Lars George <la...@gmail.com> on 2015/04/03 21:32:35 UTC
Re: Removal of deprecated features
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 <la...@gmail.com>
wrote:
> Sean, thanks for your comments.
>
> On Tue, Mar 31, 2015 at 2:09 AM, Sean Busbey <bu...@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" <la...@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
> > > >
> > >
> >
>
Re: Removal of deprecated features
Posted by Lars Francke <la...@gmail.com>.
I've created umbrella issues for 1.x and 2.0.0
2.0.0: https://issues.apache.org/jira/browse/HBASE-13462
1.x: https://issues.apache.org/jira/browse/HBASE-13465
On Tue, Apr 14, 2015 at 12:42 PM, Lars Francke <la...@gmail.com>
wrote:
> Okay I'll go with another option. As I don't have as much time as I'd like
> to I'll just split this into arbitrary chunks and will create a new JIRA
> every time I'll have to stop working on this. Fortunately this stuff is
> independent and easily done in small increments.
>
> I'll create the first JIRAs and post patches now.
>
> On Tue, Apr 7, 2015 at 10:29 PM, Lars Francke <la...@gmail.com>
> wrote:
>
>> Hmm...that'd work too but is a bit more arbitrary as some patches were
>> cross-cutting...I don't really have an opinion though :)
>>
>> On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>
>>> How about an issue per module? Should end up being somewhere between
>>> those
>>> two.
>>>
>>> --
>>> Sean
>>> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
>>>
>>> > Great, thanks everyone for your input.
>>> >
>>> > I started to go through the issues.
>>> >
>>> > I see two options: 1) One issue per "source" issue or 2) one issue per
>>> > version.
>>> >
>>> > Examples:
>>> > 1) Create new issues like this "Handle deprecations for HBASE-9870" and
>>> > then attach two patches (one for branch-1 and one for master,
>>> documenting
>>> > deprecation and removing them respectively). This would mean lots of
>>> small
>>> > issues, easy to review, easy to keep updated, easy to commit. Collect
>>> them
>>> > all in an umbrella issue.
>>> >
>>> > 2) Create a new issue "Document deprecations in branch-1" and another
>>> one
>>> > "Remove deprecations for 2.0.0" with a big patch attached to each.
>>> >
>>> > I prefer version 1 even though it'd be a lot of small patches. Release
>>> > notes could be per issue or collected in an umbrella issue.
>>> >
>>> > Any opinions? If I don't hear any I'll go ahead with that and will
>>> start
>>> > filing.
>>> >
>>> > Cheers,
>>> > Lars
>>> >
>>> >
>>> >
>>> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
>>> >
>>> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>> > >
>>> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <
>>> lars.francke@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > 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 :)
>>> > > > >
>>> > > > >
>>> > > >
>>> > > > FWIW, this works for me. The lack of complaints leads me to
>>> believe it
>>> > > > works for other PMCs. ;)
>>> > > >
>>> > > >
>>> > > Works for me (though quiet, have been following closely -- as are
>>> others
>>> > > I'd think).
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > > Please make sure these removals have good release notes. Folks who
>>> know
>>> > > > what their API usage looks like should have a heads up prior to
>>> > > > recompiling. (I'm happy to help iterate on release notes once you
>>> get
>>> > to
>>> > > > that point.)
>>> > > >
>>> > > >
>>> > > Good idea (umbrella issue to tie the efforts together).
>>> > >
>>> > > Thanks LarsF,
>>> > > St.Ack
>>> > >
>>> >
>>>
>>
>>
>
Re: Removal of deprecated features
Posted by Lars Francke <la...@gmail.com>.
Okay I'll go with another option. As I don't have as much time as I'd like
to I'll just split this into arbitrary chunks and will create a new JIRA
every time I'll have to stop working on this. Fortunately this stuff is
independent and easily done in small increments.
I'll create the first JIRAs and post patches now.
On Tue, Apr 7, 2015 at 10:29 PM, Lars Francke <la...@gmail.com>
wrote:
> Hmm...that'd work too but is a bit more arbitrary as some patches were
> cross-cutting...I don't really have an opinion though :)
>
> On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> How about an issue per module? Should end up being somewhere between those
>> two.
>>
>> --
>> Sean
>> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
>>
>> > Great, thanks everyone for your input.
>> >
>> > I started to go through the issues.
>> >
>> > I see two options: 1) One issue per "source" issue or 2) one issue per
>> > version.
>> >
>> > Examples:
>> > 1) Create new issues like this "Handle deprecations for HBASE-9870" and
>> > then attach two patches (one for branch-1 and one for master,
>> documenting
>> > deprecation and removing them respectively). This would mean lots of
>> small
>> > issues, easy to review, easy to keep updated, easy to commit. Collect
>> them
>> > all in an umbrella issue.
>> >
>> > 2) Create a new issue "Document deprecations in branch-1" and another
>> one
>> > "Remove deprecations for 2.0.0" with a big patch attached to each.
>> >
>> > I prefer version 1 even though it'd be a lot of small patches. Release
>> > notes could be per issue or collected in an umbrella issue.
>> >
>> > Any opinions? If I don't hear any I'll go ahead with that and will start
>> > filing.
>> >
>> > Cheers,
>> > Lars
>> >
>> >
>> >
>> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
>> >
>> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
>> wrote:
>> > >
>> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <
>> lars.francke@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > 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 :)
>> > > > >
>> > > > >
>> > > >
>> > > > FWIW, this works for me. The lack of complaints leads me to believe
>> it
>> > > > works for other PMCs. ;)
>> > > >
>> > > >
>> > > Works for me (though quiet, have been following closely -- as are
>> others
>> > > I'd think).
>> > >
>> > >
>> > >
>> > >
>> > > > Please make sure these removals have good release notes. Folks who
>> know
>> > > > what their API usage looks like should have a heads up prior to
>> > > > recompiling. (I'm happy to help iterate on release notes once you
>> get
>> > to
>> > > > that point.)
>> > > >
>> > > >
>> > > Good idea (umbrella issue to tie the efforts together).
>> > >
>> > > Thanks LarsF,
>> > > St.Ack
>> > >
>> >
>>
>
>
Re: Removal of deprecated features
Posted by Mikhail Antonov <ol...@gmail.com>.
Right, that's my perception on that too.
-Mikhail
On Tue, Apr 14, 2015 at 9:50 AM, Nick Dimiduk <nd...@gmail.com> wrote:
> On Thu, Apr 9, 2015 at 12:44 AM, Mikhail Antonov <ol...@gmail.com>
> wrote:
>
>> Semver states that "MAJOR version when you make incompatible API
>> changes". I read it literally as "in 2.0 you can remove anything
>> compared to 1.0". Realistically, that probably means we can at least
>> remove APIs which could be relatively easily replaced on the user side
>> following the release notes? Am I interpreting this incorrectly?
>>
>
> I believe you have the right of it. Just because we can remove arbitrarily
> doesn't mean we should. I don't think you'll see a policy resolve from this
> thread, though the consensus seems to be "remove with caution". Probably
> the best approach is to file tickets per domain, mark them for 2.0, and
> decisions will be made locally.
>
> On Tue, Apr 7, 2015 at 1:29 PM, Lars Francke <la...@gmail.com> wrote:
>> > Hmm...that'd work too but is a bit more arbitrary as some patches were
>> > cross-cutting...I don't really have an opinion though :)
>> >
>> > On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
>> >
>> >> How about an issue per module? Should end up being somewhere between
>> those
>> >> two.
>> >>
>> >> --
>> >> Sean
>> >> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
>> >>
>> >> > Great, thanks everyone for your input.
>> >> >
>> >> > I started to go through the issues.
>> >> >
>> >> > I see two options: 1) One issue per "source" issue or 2) one issue per
>> >> > version.
>> >> >
>> >> > Examples:
>> >> > 1) Create new issues like this "Handle deprecations for HBASE-9870"
>> and
>> >> > then attach two patches (one for branch-1 and one for master,
>> documenting
>> >> > deprecation and removing them respectively). This would mean lots of
>> >> small
>> >> > issues, easy to review, easy to keep updated, easy to commit. Collect
>> >> them
>> >> > all in an umbrella issue.
>> >> >
>> >> > 2) Create a new issue "Document deprecations in branch-1" and another
>> one
>> >> > "Remove deprecations for 2.0.0" with a big patch attached to each.
>> >> >
>> >> > I prefer version 1 even though it'd be a lot of small patches. Release
>> >> > notes could be per issue or collected in an umbrella issue.
>> >> >
>> >> > Any opinions? If I don't hear any I'll go ahead with that and will
>> start
>> >> > filing.
>> >> >
>> >> > Cheers,
>> >> > Lars
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
>> >> >
>> >> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
>> >> wrote:
>> >> > >
>> >> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <
>> lars.francke@gmail.com
>> >> >
>> >> > > > wrote:
>> >> > > >
>> >> > > > > 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 :)
>> >> > > > >
>> >> > > > >
>> >> > > >
>> >> > > > FWIW, this works for me. The lack of complaints leads me to
>> believe
>> >> it
>> >> > > > works for other PMCs. ;)
>> >> > > >
>> >> > > >
>> >> > > Works for me (though quiet, have been following closely -- as are
>> >> others
>> >> > > I'd think).
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > > Please make sure these removals have good release notes. Folks who
>> >> know
>> >> > > > what their API usage looks like should have a heads up prior to
>> >> > > > recompiling. (I'm happy to help iterate on release notes once you
>> get
>> >> > to
>> >> > > > that point.)
>> >> > > >
>> >> > > >
>> >> > > Good idea (umbrella issue to tie the efforts together).
>> >> > >
>> >> > > Thanks LarsF,
>> >> > > St.Ack
>> >> > >
>> >> >
>> >>
>>
>>
>>
>> --
>> Thanks,
>> Michael Antonov
>>
--
Thanks,
Michael Antonov
Re: Removal of deprecated features
Posted by Nick Dimiduk <nd...@gmail.com>.
On Thu, Apr 9, 2015 at 12:44 AM, Mikhail Antonov <ol...@gmail.com>
wrote:
> Semver states that "MAJOR version when you make incompatible API
> changes". I read it literally as "in 2.0 you can remove anything
> compared to 1.0". Realistically, that probably means we can at least
> remove APIs which could be relatively easily replaced on the user side
> following the release notes? Am I interpreting this incorrectly?
>
I believe you have the right of it. Just because we can remove arbitrarily
doesn't mean we should. I don't think you'll see a policy resolve from this
thread, though the consensus seems to be "remove with caution". Probably
the best approach is to file tickets per domain, mark them for 2.0, and
decisions will be made locally.
On Tue, Apr 7, 2015 at 1:29 PM, Lars Francke <la...@gmail.com> wrote:
> > Hmm...that'd work too but is a bit more arbitrary as some patches were
> > cross-cutting...I don't really have an opinion though :)
> >
> > On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> >> How about an issue per module? Should end up being somewhere between
> those
> >> two.
> >>
> >> --
> >> Sean
> >> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
> >>
> >> > Great, thanks everyone for your input.
> >> >
> >> > I started to go through the issues.
> >> >
> >> > I see two options: 1) One issue per "source" issue or 2) one issue per
> >> > version.
> >> >
> >> > Examples:
> >> > 1) Create new issues like this "Handle deprecations for HBASE-9870"
> and
> >> > then attach two patches (one for branch-1 and one for master,
> documenting
> >> > deprecation and removing them respectively). This would mean lots of
> >> small
> >> > issues, easy to review, easy to keep updated, easy to commit. Collect
> >> them
> >> > all in an umbrella issue.
> >> >
> >> > 2) Create a new issue "Document deprecations in branch-1" and another
> one
> >> > "Remove deprecations for 2.0.0" with a big patch attached to each.
> >> >
> >> > I prefer version 1 even though it'd be a lot of small patches. Release
> >> > notes could be per issue or collected in an umbrella issue.
> >> >
> >> > Any opinions? If I don't hear any I'll go ahead with that and will
> start
> >> > filing.
> >> >
> >> > Cheers,
> >> > Lars
> >> >
> >> >
> >> >
> >> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
> >> >
> >> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
> >> wrote:
> >> > >
> >> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <
> lars.francke@gmail.com
> >> >
> >> > > > wrote:
> >> > > >
> >> > > > > 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 :)
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > FWIW, this works for me. The lack of complaints leads me to
> believe
> >> it
> >> > > > works for other PMCs. ;)
> >> > > >
> >> > > >
> >> > > Works for me (though quiet, have been following closely -- as are
> >> others
> >> > > I'd think).
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > > Please make sure these removals have good release notes. Folks who
> >> know
> >> > > > what their API usage looks like should have a heads up prior to
> >> > > > recompiling. (I'm happy to help iterate on release notes once you
> get
> >> > to
> >> > > > that point.)
> >> > > >
> >> > > >
> >> > > Good idea (umbrella issue to tie the efforts together).
> >> > >
> >> > > Thanks LarsF,
> >> > > St.Ack
> >> > >
> >> >
> >>
>
>
>
> --
> Thanks,
> Michael Antonov
>
Re: Removal of deprecated features
Posted by Mikhail Antonov <ol...@gmail.com>.
I'm probably late to this thread, but just given some comments to
HBASE-13395 wanted to follow up here.
Semver states that "MAJOR version when you make incompatible API
changes". I read it literally as "in 2.0 you can remove anything
compared to 1.0". Realistically, that probably means we can at least
remove APIs which could be relatively easily replaced on the user side
following the release notes? Am I interpreting this incorrectly?
-Mikhail
On Tue, Apr 7, 2015 at 1:29 PM, Lars Francke <la...@gmail.com> wrote:
> Hmm...that'd work too but is a bit more arbitrary as some patches were
> cross-cutting...I don't really have an opinion though :)
>
> On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> How about an issue per module? Should end up being somewhere between those
>> two.
>>
>> --
>> Sean
>> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
>>
>> > Great, thanks everyone for your input.
>> >
>> > I started to go through the issues.
>> >
>> > I see two options: 1) One issue per "source" issue or 2) one issue per
>> > version.
>> >
>> > Examples:
>> > 1) Create new issues like this "Handle deprecations for HBASE-9870" and
>> > then attach two patches (one for branch-1 and one for master, documenting
>> > deprecation and removing them respectively). This would mean lots of
>> small
>> > issues, easy to review, easy to keep updated, easy to commit. Collect
>> them
>> > all in an umbrella issue.
>> >
>> > 2) Create a new issue "Document deprecations in branch-1" and another one
>> > "Remove deprecations for 2.0.0" with a big patch attached to each.
>> >
>> > I prefer version 1 even though it'd be a lot of small patches. Release
>> > notes could be per issue or collected in an umbrella issue.
>> >
>> > Any opinions? If I don't hear any I'll go ahead with that and will start
>> > filing.
>> >
>> > Cheers,
>> > Lars
>> >
>> >
>> >
>> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
>> >
>> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
>> wrote:
>> > >
>> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <lars.francke@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > > > 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 :)
>> > > > >
>> > > > >
>> > > >
>> > > > FWIW, this works for me. The lack of complaints leads me to believe
>> it
>> > > > works for other PMCs. ;)
>> > > >
>> > > >
>> > > Works for me (though quiet, have been following closely -- as are
>> others
>> > > I'd think).
>> > >
>> > >
>> > >
>> > >
>> > > > Please make sure these removals have good release notes. Folks who
>> know
>> > > > what their API usage looks like should have a heads up prior to
>> > > > recompiling. (I'm happy to help iterate on release notes once you get
>> > to
>> > > > that point.)
>> > > >
>> > > >
>> > > Good idea (umbrella issue to tie the efforts together).
>> > >
>> > > Thanks LarsF,
>> > > St.Ack
>> > >
>> >
>>
--
Thanks,
Michael Antonov
Re: Removal of deprecated features
Posted by Lars Francke <la...@gmail.com>.
Hmm...that'd work too but is a bit more arbitrary as some patches were
cross-cutting...I don't really have an opinion though :)
On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bu...@cloudera.com> wrote:
> How about an issue per module? Should end up being somewhere between those
> two.
>
> --
> Sean
> On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
>
> > Great, thanks everyone for your input.
> >
> > I started to go through the issues.
> >
> > I see two options: 1) One issue per "source" issue or 2) one issue per
> > version.
> >
> > Examples:
> > 1) Create new issues like this "Handle deprecations for HBASE-9870" and
> > then attach two patches (one for branch-1 and one for master, documenting
> > deprecation and removing them respectively). This would mean lots of
> small
> > issues, easy to review, easy to keep updated, easy to commit. Collect
> them
> > all in an umbrella issue.
> >
> > 2) Create a new issue "Document deprecations in branch-1" and another one
> > "Remove deprecations for 2.0.0" with a big patch attached to each.
> >
> > I prefer version 1 even though it'd be a lot of small patches. Release
> > notes could be per issue or collected in an umbrella issue.
> >
> > Any opinions? If I don't hear any I'll go ahead with that and will start
> > filing.
> >
> > Cheers,
> > Lars
> >
> >
> >
> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com>
> wrote:
> > >
> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <lars.francke@gmail.com
> >
> > > > wrote:
> > > >
> > > > > 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 :)
> > > > >
> > > > >
> > > >
> > > > FWIW, this works for me. The lack of complaints leads me to believe
> it
> > > > works for other PMCs. ;)
> > > >
> > > >
> > > Works for me (though quiet, have been following closely -- as are
> others
> > > I'd think).
> > >
> > >
> > >
> > >
> > > > Please make sure these removals have good release notes. Folks who
> know
> > > > what their API usage looks like should have a heads up prior to
> > > > recompiling. (I'm happy to help iterate on release notes once you get
> > to
> > > > that point.)
> > > >
> > > >
> > > Good idea (umbrella issue to tie the efforts together).
> > >
> > > Thanks LarsF,
> > > St.Ack
> > >
> >
>
Re: Removal of deprecated features
Posted by Sean Busbey <bu...@cloudera.com>.
How about an issue per module? Should end up being somewhere between those
two.
--
Sean
On Apr 7, 2015 7:21 AM, "Lars Francke" <la...@gmail.com> wrote:
> Great, thanks everyone for your input.
>
> I started to go through the issues.
>
> I see two options: 1) One issue per "source" issue or 2) one issue per
> version.
>
> Examples:
> 1) Create new issues like this "Handle deprecations for HBASE-9870" and
> then attach two patches (one for branch-1 and one for master, documenting
> deprecation and removing them respectively). This would mean lots of small
> issues, easy to review, easy to keep updated, easy to commit. Collect them
> all in an umbrella issue.
>
> 2) Create a new issue "Document deprecations in branch-1" and another one
> "Remove deprecations for 2.0.0" with a big patch attached to each.
>
> I prefer version 1 even though it'd be a lot of small patches. Release
> notes could be per issue or collected in an umbrella issue.
>
> Any opinions? If I don't hear any I'll go ahead with that and will start
> filing.
>
> Cheers,
> Lars
>
>
>
> On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
>
> > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <la...@gmail.com>
> > > wrote:
> > >
> > > > 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 :)
> > > >
> > > >
> > >
> > > FWIW, this works for me. The lack of complaints leads me to believe it
> > > works for other PMCs. ;)
> > >
> > >
> > Works for me (though quiet, have been following closely -- as are others
> > I'd think).
> >
> >
> >
> >
> > > Please make sure these removals have good release notes. Folks who know
> > > what their API usage looks like should have a heads up prior to
> > > recompiling. (I'm happy to help iterate on release notes once you get
> to
> > > that point.)
> > >
> > >
> > Good idea (umbrella issue to tie the efforts together).
> >
> > Thanks LarsF,
> > St.Ack
> >
>
Re: Removal of deprecated features
Posted by Lars Francke <la...@gmail.com>.
Great, thanks everyone for your input.
I started to go through the issues.
I see two options: 1) One issue per "source" issue or 2) one issue per
version.
Examples:
1) Create new issues like this "Handle deprecations for HBASE-9870" and
then attach two patches (one for branch-1 and one for master, documenting
deprecation and removing them respectively). This would mean lots of small
issues, easy to review, easy to keep updated, easy to commit. Collect them
all in an umbrella issue.
2) Create a new issue "Document deprecations in branch-1" and another one
"Remove deprecations for 2.0.0" with a big patch attached to each.
I prefer version 1 even though it'd be a lot of small patches. Release
notes could be per issue or collected in an umbrella issue.
Any opinions? If I don't hear any I'll go ahead with that and will start
filing.
Cheers,
Lars
On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote:
> On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <la...@gmail.com>
> > wrote:
> >
> > > 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 :)
> > >
> > >
> >
> > FWIW, this works for me. The lack of complaints leads me to believe it
> > works for other PMCs. ;)
> >
> >
> Works for me (though quiet, have been following closely -- as are others
> I'd think).
>
>
>
>
> > Please make sure these removals have good release notes. Folks who know
> > what their API usage looks like should have a heads up prior to
> > recompiling. (I'm happy to help iterate on release notes once you get to
> > that point.)
> >
> >
> Good idea (umbrella issue to tie the efforts together).
>
> Thanks LarsF,
> St.Ack
>
Re: Removal of deprecated features
Posted by Stack <st...@duboce.net>.
On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <la...@gmail.com>
> wrote:
>
> > 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 :)
> >
> >
>
> FWIW, this works for me. The lack of complaints leads me to believe it
> works for other PMCs. ;)
>
>
Works for me (though quiet, have been following closely -- as are others
I'd think).
> Please make sure these removals have good release notes. Folks who know
> what their API usage looks like should have a heads up prior to
> recompiling. (I'm happy to help iterate on release notes once you get to
> that point.)
>
>
Good idea (umbrella issue to tie the efforts together).
Thanks LarsF,
St.Ack
Re: Removal of deprecated features
Posted by Michael Segel <mi...@hotmail.com>.
You have to understand that anyone who has a slow moving (changing) application, will also have a UAT / DEV area where they can test the impact of any system upgrade. So if the upgrade breaks their app, they will be able to catch it before going in to production.
> On Apr 6, 2015, at 10:20 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <lars.francke@gmail.com <ma...@gmail.com>> wrote:
>
>> 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 :)
>>
>>
>
> FWIW, this works for me. The lack of complaints leads me to believe it
> works for other PMCs. ;)
>
> Please make sure these removals have good release notes. Folks who know
> what their API usage looks like should have a heads up prior to
> recompiling. (I'm happy to help iterate on release notes once you get to
> that point.)
>
>
>> Any (git) hints on how to figure out for which tag something was first
>> marked deprecated are welcome too...
>>
>>
> You should be able to get an approximation using git blame and git tag
> --contains.
>
> eg:
>
> $> git checkout 1.0.0
> $> git blame -s
> hbase-client/src/main/java//org/apache/hadoop/hbase/client/Put.java | grep
> -i -A 2 "@deprecated"
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 140) * @deprecated Since 1.0.0. Use {@link #addColumn(byte[], byte[],
> byte[])}
> 6af42926 src/java/org/apache/hadoop/hbase/client/Put.java
> 141) */
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 142) @Deprecated
> 1115f46d src/java/org/apache/hadoop/hbase/client/Put.java
> 143) public Put add(byte [] family, byte [] qualifier, byte [] value) {
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 144) return addColumn(family, qualifier, value);
> --
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 183) * @deprecated Since 1.0.0. Use {@link #addColumn(byte[], byte[],
> long, byte[])}
> 6af42926 src/java/org/apache/hadoop/hbase/client/Put.java
> 184) */
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 185) @Deprecated
> 1115f46d src/java/org/apache/hadoop/hbase/client/Put.java
> 186) public Put add(byte [] family, byte [] qualifier, long ts, byte []
> value) {
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 187) return addColumn(family, qualifier, ts, value);
> --
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 263) * @deprecated Since 1.0.0. Use {@link Put#addColumn(byte[],
> ByteBuffer, long, ByteBuffer)}
> dc8ecd9a hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 264) */
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 265) @Deprecated
> dc8ecd9a hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 266) public Put add(byte[] family, ByteBuffer qualifier, long ts,
> ByteBuffer value) {
> c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 267) return addColumn(family, qualifier, ts, value);
> --
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 477) @Deprecated
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 478) public Put setWriteToWAL(boolean write) {
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 479) return (Put) super.setWriteToWAL(write);
> --
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 493) @Deprecated
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 494) public Put setFamilyMap(NavigableMap<byte[], List<KeyValue>> map) {
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 495) return (Put) super.setFamilyMap(map);
> $> git tag --contains c4d58162
> 1.0.0
> 1.0.0RC5
>
> So it looks like the three listed versions of add were present as of 1.0.0,
> so we can remove them in 2.0.0.
>
> The one exception to this is if the deprecation doc was altered after it
> was added, for example to add a proper message. To check for that case
> case, you need to look at the version prior to the one above to confirm.
> (rev^ means "the version before rev")
>
> $> git blame -s c4d58162^
> hbase-client/src/main/java//org/apache/hadoop/hbase/client/Put.java | grep
> -i -A 2 "@deprecated"
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 435) @Deprecated
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 436) public Put setWriteToWAL(boolean write) {
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 437) return (Put) super.setWriteToWAL(write);
> --
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 451) @Deprecated
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 452) public Put setFamilyMap(NavigableMap<byte[], List<KeyValue>> map) {
> 73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
> 453) return (Put) super.setFamilyMap(map);
>
>
> A limitation of this approach in combination with our branching model is
> that it'll only find when the change happened within one major development
> line. For example, if you do the above in the master branch you won't find
> the @deprecated in a release because it was added after we added branch-1.
>
> --
> Sean
The opinions expressed here are mine, while they may reflect a cognitive thought, that is purely accidental.
Use at your own risk.
Michael Segel
michael_segel (AT) hotmail.com
Re: Removal of deprecated features
Posted by Sean Busbey <bu...@cloudera.com>.
On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <la...@gmail.com> wrote:
> 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 :)
>
>
FWIW, this works for me. The lack of complaints leads me to believe it
works for other PMCs. ;)
Please make sure these removals have good release notes. Folks who know
what their API usage looks like should have a heads up prior to
recompiling. (I'm happy to help iterate on release notes once you get to
that point.)
> Any (git) hints on how to figure out for which tag something was first
> marked deprecated are welcome too...
>
>
You should be able to get an approximation using git blame and git tag
--contains.
eg:
$> git checkout 1.0.0
$> git blame -s
hbase-client/src/main/java//org/apache/hadoop/hbase/client/Put.java | grep
-i -A 2 "@deprecated"
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
140) * @deprecated Since 1.0.0. Use {@link #addColumn(byte[], byte[],
byte[])}
6af42926 src/java/org/apache/hadoop/hbase/client/Put.java
141) */
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
142) @Deprecated
1115f46d src/java/org/apache/hadoop/hbase/client/Put.java
143) public Put add(byte [] family, byte [] qualifier, byte [] value) {
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
144) return addColumn(family, qualifier, value);
--
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
183) * @deprecated Since 1.0.0. Use {@link #addColumn(byte[], byte[],
long, byte[])}
6af42926 src/java/org/apache/hadoop/hbase/client/Put.java
184) */
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
185) @Deprecated
1115f46d src/java/org/apache/hadoop/hbase/client/Put.java
186) public Put add(byte [] family, byte [] qualifier, long ts, byte []
value) {
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
187) return addColumn(family, qualifier, ts, value);
--
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
263) * @deprecated Since 1.0.0. Use {@link Put#addColumn(byte[],
ByteBuffer, long, ByteBuffer)}
dc8ecd9a hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
264) */
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
265) @Deprecated
dc8ecd9a hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
266) public Put add(byte[] family, ByteBuffer qualifier, long ts,
ByteBuffer value) {
c4d58162 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
267) return addColumn(family, qualifier, ts, value);
--
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
477) @Deprecated
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
478) public Put setWriteToWAL(boolean write) {
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
479) return (Put) super.setWriteToWAL(write);
--
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
493) @Deprecated
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
494) public Put setFamilyMap(NavigableMap<byte[], List<KeyValue>> map) {
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
495) return (Put) super.setFamilyMap(map);
$> git tag --contains c4d58162
1.0.0
1.0.0RC5
So it looks like the three listed versions of add were present as of 1.0.0,
so we can remove them in 2.0.0.
The one exception to this is if the deprecation doc was altered after it
was added, for example to add a proper message. To check for that case
case, you need to look at the version prior to the one above to confirm.
(rev^ means "the version before rev")
$> git blame -s c4d58162^
hbase-client/src/main/java//org/apache/hadoop/hbase/client/Put.java | grep
-i -A 2 "@deprecated"
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
435) @Deprecated
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
436) public Put setWriteToWAL(boolean write) {
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
437) return (Put) super.setWriteToWAL(write);
--
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
451) @Deprecated
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
452) public Put setFamilyMap(NavigableMap<byte[], List<KeyValue>> map) {
73731d92 hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java
453) return (Put) super.setFamilyMap(map);
A limitation of this approach in combination with our branching model is
that it'll only find when the change happened within one major development
line. For example, if you do the above in the master branch you won't find
the @deprecated in a release because it was added after we added branch-1.
--
Sean
Re: Removal of deprecated features
Posted by Lars Francke <la...@gmail.com>.
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 <la...@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 <la...@gmail.com>
> wrote:
>
> > Sean, thanks for your comments.
> >
> > On Tue, Mar 31, 2015 at 2:09 AM, Sean Busbey <bu...@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" <la...@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
> > > > >
> > > >
> > >
> >
>