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