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 16:55:22 GMT
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 <lars.francke@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 <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