accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kepner, Jeremy - 0553 - MITLL" <kep...@ll.mit.edu>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 20:19:23 GMT
So I think the bigger issue is to revisit the imperative to delete deprecated functions (both
public & private).  How many instances have we had where deleting a deprecated API (public
& private) did anything more than "clean up" the code?

On Dec 11, 2014, at 2:39 PM, John Vines <vines@apache.org> wrote:

> More likely we'd have a fully backwards compatible API for each major
> version. SemVer allows for it and I think that grants us enough room for
> growth while still securing things for future releases.
> 
> On Thu, Dec 11, 2014 at 2:36 PM, Adam Fuchs <afuchs@apache.org> wrote:
> 
>> Awesome -- ACCUMULO-2589 gets us at least halfway there. Given this,
>> what would be the challenges in having and maintaining one API project
>> for each major version ever released?
>> 
>> Adam
>> 
>> On Thu, Dec 11, 2014 at 2:24 PM, Josh Elser <josh.elser@gmail.com> wrote:
>>> Adam Fuchs 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?
>>> 
>>> 
>>> Yup, this is already in the works by Christopher as a part of
>> ACCUMULO-2589.
>>> 
>>> 
>>>> 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.
>>>>>>>>>>> 
>>> 
>> 


Mime
View raw message