accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Kepner <kep...@ll.mit.edu>
Subject Re: Deprecation removal for 1.7.0
Date Wed, 08 Oct 2014 21:25:56 GMT
Some of us are lobbying to undue some of 1.6.0 deletions since a lot of big customers
are still on 1.4.0 and won't be getting to 1.6.0 for a while.

Basically, deprecation should be sufficient warning to not use a function.

Deletion should be reserved only for those occasions where keeping the function in
will be break the system.

These are all good problems to have.  It means folks are really
using Accumulo.


On Wed, Oct 08, 2014 at 04:53:38PM -0400, Keith Turner wrote:
> On Wed, Oct 8, 2014 at 4:48 PM, Mike Drob <madrob@cloudera.com> wrote:
> 
> > Applications that worked with Accumulo 1.4 may or may not work with 1.6
> > already (we've made a lot of changes to the InputFormat, for example) so
> > trying to promise compatibility with 2.0 sounds like a very losing battle.
> >
> 
> 
> Fair point.  The 1.6.0 release notes[1] outline deprecated methods that
> were dropped  in the "API Changes" section ( and I think I wrote some of
> that).
> 
> [1]: http://accumulo.apache.org/release_notes/1.6.0.html
> 
> 
> >
> > On Wed, Oct 8, 2014 at 3:44 PM, Keith Turner <keith@deenlo.com> wrote:
> >
> > > 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
View raw message