accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Deprecation removal for 1.7.0
Date Tue, 07 Oct 2014 19:52:10 GMT
Also, the way I looked was simply to search for references in o.a.a.* for
@Deprecated.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Tue, Oct 7, 2014 at 3:42 PM, Christopher <ctubbsii@apache.org> wrote:

> Well, the right way to do that is with API compatibility checks, like with
> clirr-maven-plugin.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Tue, Oct 7, 2014 at 3:10 PM, Mike Drob <madrob@cloudera.com> wrote:
>
>> Not all of our developers use Eclipse, so if something is important, we
>> need a way to make it break a jenkins build.
>>
>> On Tue, Oct 7, 2014 at 2:03 PM, Bill Havanki <bhavanki@clouderagovt.com>
>> wrote:
>>
>> > I took a look at Christopher's commits for ACCUMULO-3197 and they all
>> look
>> > fine to me. Any other reviewers may like to add "?w=1" to the URL for
>> each
>> > commit to ignore whitespace-only changes in the view, e.g.:
>> >
>> >
>> >
>> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
>> > *?w=1*
>> >
>> > Going forward, it'd be nice to have a rule of thumb for how long a
>> > deprecated item will linger: some possibilities:
>> >
>> > - 2 minor releases or the next major release, whichever comes first
>> > - always until the next major release (this may make sense starting with
>> > 2.0.0)
>> >
>> > I like the idea of a tool to find use of deprecated calls; it appears
>> that
>> > Eclipse and Sonar can do that:
>> >
>> >
>> >
>> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>> >
>> > Overall, +1 to removing deprecations from 1.4 and earlier.
>> >
>> > Bill
>> >
>> >
>> > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ctubbsii@apache.org>
>> wrote:
>> >
>> > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <afuchs@apache.org> wrote:
>> > >
>> > > > So, I think we can make a general argument to set policy, and when
>> > > removing
>> > > > a specific method we should make a specific argument. Personally,
I
>> > would
>> > > > set the bar at identifying the specific harm cause by the retention
>> of
>> > > the
>> > > > method, as well as polling the community and considering objections.
>> > > >
>> > > > Christopher, you made an argument about people misunderstanding the
>> > > > semantics of the method and using it incorrectly. Is that not
>> solved by
>> > > > just deprecating the method?
>> > > >
>> > > >
>> > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and
>> it
>> > was
>> > > deprecated in 1.6.0. Further, it was hard to notice because:
>> > >
>> > > 1) it's the only way to currently get that information from the API to
>> > the
>> > > RPC layer (see ACCUMULO-3199)
>> > > (In my proposed commit[1], I offer a temporary workaround which
>> involves
>> > > better naming, and limits the API to the ZooKeeperInstance only)
>> > > 2) the use of the method occurred in a somewhat badly named utility
>> > method
>> > > which suppressed deprecation warnings
>> > >
>> > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
>> to
>> > > get the user-provided client RPC config to the RPC layer, this method
>> is
>> > > going to be prone to abuse.
>> > >
>> > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
>> > >
>> > > --
>> > > Christopher L Tubbs II
>> > > http://gravatar.com/ctubbsii
>> > >
>> >
>> >
>> >
>> > --
>> > // Bill Havanki
>> > // Solutions Architect, Cloudera Govt Solutions
>> > // 443.686.9283
>> >
>>
>
>

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