hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Removal of deprecated features
Date Tue, 14 Apr 2015 16:50:27 GMT
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
>

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