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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> > >> > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <[email protected]> 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 >> > >> > >
