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 Wed, 08 Oct 2014 23:57:24 GMT
On Wed, Oct 8, 2014 at 5:25 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:

> 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.
>
>
Where, specifically, are these being lobbied? Please ensure these have
corresponding JIRAs.


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message