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:51:30 GMT
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*
>
>
Note: I rebase'd:
https://github.com/ctubbsii/accumulo/commit/ded90c7?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 think the rule for 2.0 and later should be: don't remove until it has
been deprecated for a full major release (with exceptions on a case-by-case
basis, with good reasons). Example: if something is deprecated in 2.0.5, it
cannot be removed until 4.0.0. If it's deprecated in 2.0.0, it can be
removed in 3.0.0.

My only concern today is the 1.x stuff, though. If we want to be as strict
for 1.x as we plan to be for 2.x and later, then we can go ahead and adopt
the "keep it until 2.0.0" mentality, unless there's a good reason. If we do
that (which we haven't done in prevoius 1.x releases, but I'm fine with),
then the only thing here left to discuss would be whether the
Instance.getConfiguration() stuff is a good exception to the rule.


> 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