accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Deprecation removal for 1.7.0
Date Tue, 07 Oct 2014 19:52:59 GMT
I like the idea of leaving deprecated things until the next major
release (2.0.0 in this case). It would encourage us to choose
carefully what APIs we add :)

On Tue, Oct 7, 2014 at 3: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
View raw message