accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 19:24:24 GMT
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