hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <olorinb...@gmail.com>
Subject Re: Removal of deprecated features
Date Tue, 14 Apr 2015 18:33:03 GMT
Right, that's my perception on that too.

-Mikhail

On Tue, Apr 14, 2015 at 9:50 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
> On Thu, Apr 9, 2015 at 12:44 AM, Mikhail Antonov <olorinbant@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 <lars.francke@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 <busbey@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" <lars.francke@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 <stack@duboce.net> wrote:
>> >> >
>> >> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <busbey@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

Mime
View raw message