Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAPMpPc6SNKGrT0dAoOYn=8_9RBs8iBONFMuWGga+3Kf3yyWR7A@mail.gmail.com>
References: 
 <CAL5zq9a=iFv_t2yy-QftiPFSLUjYK7DhVrPOUcqF8-wKNhzQVQ@mail.gmail.com>
	<20141211154421.GB10400@ll.mit.edu>
	<5489C276.7080009@gmail.com>
	<5489C69D.8040301@gmail.com>
	<1DA7322C-B49D-4BA2-974E-0E945CCCC0A6@ll.mit.edu>
	<CADczPYSHKCDU_rqgsD5eo2DAzONocoVDE-nX0d6b475uLSC0ag@mail.gmail.com>
	<CAF1jEfDP5928QaAeGo2_jO7Wm=dBezcTP-ECYcyGZBLBf+Q8mA@mail.gmail.com>
	<CAFAMeYLjQY-6dhVZWJXBTc+bBu8AS+OxOgbCGV_owR2kyYnDtg@mail.gmail.com>
	<CAF1jEfCG5ntZacpEytDHt+pELWC1k1OCsVNhQ1dYW8dNVH9f_w@mail.gmail.com>
	<CAL5zq9YW=C3E5-=2PEf5WcrM-9D4UKVXwfefw4CV=P1iSDwO-Q@mail.gmail.com>
	<20141211185403.GA10747@ll.mit.edu>
	<CAPMpPc6SNKGrT0dAoOYn=8_9RBs8iBONFMuWGga+3Kf3yyWR7A@mail.gmail.com>
Date: Thu, 11 Dec 2014 16:34:12 -0500
Message-ID: 
 <CAL5zq9amf+wFUjYHFR=TqvVvU5mha43JDNHAdifv5u+YxUeq9Q@mail.gmail.com>
Subject: Re: Official Guidance to users regarding removal of functions
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a1135f3a4895a760509f789ed

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

In addition to the responses already provided, I think it'd be better to
just continue supporting 1.x with new features/bugfixes as long as there is
demand for it, would be preferred than trying to keep a 1.x shim API on top
of newer releases.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Thu, Dec 11, 2014 at 2:22 PM, Adam Fuchs <afuchs@apache.org> wrote:

> Has anybody looked into separating the public API a bit more from the
> core? It seems to me that a large number of the deprecation removal
> issues are related to people failing to read section 9 of the README.
> It would be great if we built an API jar that people could build
> against, but didn't leak internal classes. Maybe this is something we
> can shoot for in the 2.0 release?
>
> Taking that a step further, it would be great if we released a 1.x API
> compatible client jar for every 2.x or later release. Does anybody
> have a feel for the maintenance costs of such a thing? Certainly
> changes to configuration options and metadata table structures will
> prove challenging. Given that we don't have a history of removing
> functionality, this ought to at least be feasible.
>
> Thoughts?
>
> Adam
>
>
> On Thu, Dec 11, 2014 at 1:54 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:
> > So the simple solution is to deprecate often, but remove almost never.
> > It is very rare that leaving a deprecated API in place actually has a
> negative impact.
> > The code gets a little less clean, but that's fine as long as things are
> clearly labeled as deprecated.
> > In fact, seeing the way something used to be done can often be an
> inspiration for something new.
> > If the past is deleted, then that knowledge is lost.
> >
> > I am not saying deleting can never happen, I am just saying that when it
> does, it is because
> > there absolutely no choice.  Deletion to "clean up the code" shouldn't
> be a valid reason for deletion.
> >
> > On Thu, Dec 11, 2014 at 12:58:13PM -0500, Christopher wrote:
> >> I don't know that it'd be "cold comfort". We can continue to support 1.x
> >> for some time, if we choose.
> >>
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >> On Thu, Dec 11, 2014 at 12:53 PM, Billie Rinaldi <billie@apache.org>
> wrote:
> >>
> >> > Actually, I wasn't suggesting anything.  I was providing elaboration
> on
> >> > what John was referring to.  I imagine that stronger API guarantees
> will be
> >> > cold comfort in the face of a 1.0 -> 2.0 upgrade.  However, if we had
> been
> >> > using semver all along, there would have been much less pain for
> users in
> >> > the 1.x series.  Also, adopting semver would mean that going from 1.6
> to a
> >> > hypothetical 1.7 would not suffer from the same upgrade issues.  I
> doubt
> >> > that we could retroactively mitigate the differences in minor
> versions,
> >> > though, so going from 1.3/1.4/1.5 to 1.7 would still be hard.
> >> >
> >> > On Thu, Dec 11, 2014 at 9:11 AM, Mike Drob <madrob@cloudera.com>
> wrote:
> >> >
> >> > > Billie,
> >> > >
> >> > > Not to be glib, but it reads like your suggestion to Jeremy for
> when we
> >> > > have a 2.0.0 release (assuming semver passes) is to take option (2)
> Don't
> >> > > upgrade Accumulo.
> >> > >
> >> > > Please correct my misunderstanding.
> >> > >
> >> > > Mike
> >> > >
> >> > > On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi <billie@apache.org
> >
> >> > > wrote:
> >> > >
> >> > > > To clarify John's question: if our vote to adopt semver 2.0.0
> passes,
> >> > our
> >> > > > intention will be to no longer have breaking public API changes
> unless
> >> > > the
> >> > > > major version number is incremented, i.e. 1.x.x -> 2.x.x. An
> important
> >> > > > aspect of semantic versioning is defining what is considered part
> of
> >> > the
> >> > > > public API. So if there are things you need to remain consistent
> that
> >> > are
> >> > > > not covered by Section 9 of the README, we should discuss adding
> them.
> >> > > > Actually, strengthening what we consider to be the public API is
> likely
> >> > > to
> >> > > > be a separate conversation in which (I hope) we will engage the
> user
> >> > > list.
> >> > > > On Dec 11, 2014 11:51 AM, "John Vines" <vines@apache.org> wrote:
> >> > > >
> >> > > > > Wouldn't this be resolved with our SemVer sqwitch?
> >> > > > >
> >> > > > > On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL
> <
> >> > > > > kepner@ll.mit.edu> wrote:
> >> > > > >
> >> > > > > > When we remove functions, do we have any official guidance to
> our
> >> > > users
> >> > > > > > who may have built applications that use those functions?
> >> > > > > >
> >> > > > > > Right now, the official position is that the Accumulo
> developers
> >> > can
> >> > > > > > remove based on a consensus vote. However, this provides no
> >> > guidance
> >> > > to
> >> > > > > > users as to what they are suppose to do? As it stands, our
> guidance
> >> > > is
> >> > > > > that
> >> > > > > > they have the following choices:
> >> > > > > >
> >> > > > > > (0) Diligently watch the Accumulo e-mail list and aggressively
> >> > weigh
> >> > > in
> >> > > > > on
> >> > > > > > any vote to remove functions that may impact them.
> >> > > > > >
> >> > > > > > (1) Find someone to modify the original source code of their
> >> > > > > applications,
> >> > > > > > build it, and *re-verify* the application. I emphasise the
> >> > re-verify
> >> > > > > > because that is usually the most costly part of the process
> that
> >> > > often
> >> > > > > > won't get approved by management.
> >> > > > > >
> >> > > > > > (2) Don't upgrade Accumulo.
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
>

--001a1135f3a4895a760509f789ed--