accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: Deprecation removal for 1.7.0
Date Wed, 08 Oct 2014 20:44:55 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*
>
> 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.
>

So this in effect making the statement that Accumulo apps that worked w/
1.4 may not work w/ 2.0.0.  Is that what we want?  If this would cause
someone to not Adopt 2.0.0, is that what we would want?  Do we want to be
able to say that if your app worked w/ 1.4, it will work with 2.0.0?  If
so, 2.0.0 does not have to exist forever.  Eventually we can release 3.0.0
and break 1.4 apps.



>
> 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