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 Tue, 14 Apr 2015 10:42:51 GMT
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 <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
>> > >
>> >
>>
>
>

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