Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of mdrob@cloudera.com designates
 209.85.218.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGUtCHqXbS8S-=sLCf=CU+wHyT0G+P9bBcKppOz0bPsuNtYoQg@mail.gmail.com>
References: 
 <CAL5zq9ah+G+oMqR_p5E09Cwyue0K2ztVoJ10h+GriKOvhe+ggQ@mail.gmail.com>
 <CAGHyZ6J27j+8PB_c=gwvDPQxpTbDDmbFp4xvtfXPK3HBzMZGVA@mail.gmail.com>
 <CAL5zq9YrYiznVVNqGq04+oXTeLNf1W8K68TFKE2zGvp68TXnTg@mail.gmail.com>
 <CAFAMeYJDwGNwre+ZC+T0FnuAeEh78ncsTe31cmnhxDCtOgRnJQ@mail.gmail.com>
 <CAF1jEfAMrQE=tBTworFjom=KUDzkpQVAWAKXaG5=+d0sRZbJfQ@mail.gmail.com>
 <CAFAMeY+N80kJfsnQHXLQCC9qfTOONuFiPvx-nnPf-++FYHOiPg@mail.gmail.com>
 <CAGHyZ6LACiA6iXKmfA7vogiL5ovPmZGVsZSvTd6huisHE_=YaA@mail.gmail.com>
 <CAL5zq9Z580s8wW0BsvZd4NLfe5uXJSghazUDGOpDADk0=UXaLg@mail.gmail.com>
 <20141006214223.GA7997@ll.mit.edu>
 <CAGHyZ6Lg3MWfYfNQYhU8osZvJus=VfhBvoA0cgF44cN1j60EHw@mail.gmail.com>
 <CAPMpPc7uRYhm0KGm8UqqcZ4F9db41bWE=RUz8Zej4CU0Jv13jA@mail.gmail.com>
 <CAL5zq9ZiZuLANYyS8nefCjxiFnOPneLYv7WW4L=xJ-czdcxXwA@mail.gmail.com>
 <CAD-fFU+qpodh8YG+rmq+UgWGqSs7dO_x0WNJueoMxkzX9TY98w@mail.gmail.com>
 <CAGUtCHqXbS8S-=sLCf=CU+wHyT0G+P9bBcKppOz0bPsuNtYoQg@mail.gmail.com>
From: Mike Drob <madrob@cloudera.com>
Date: Wed, 8 Oct 2014 15:48:47 -0500
Message-ID: 
 <CAFAMeY+5ohuo7prvA=8eMT8bwmdXfJuWnK3Rr=skzNK7kCQa-g@mail.gmail.com>
Subject: Re: Deprecation removal for 1.7.0
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11c20b2c89bb2b0504ef7220

--001a11c20b2c89bb2b0504ef7220
Content-Type: text/plain; charset=UTF-8

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.

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

--001a11c20b2c89bb2b0504ef7220--