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 23:08:03 GMT
Great, thanks for the feedback. I just committed this in ACCUMULO-3403

Christopher wrote:
> Yes, I agree you should just reintroduce the method if it was removed in
> 1.7, which is not yet released.
> If it was removed in 1.6.{0,1}, you could also consider reintroducing it
> for 1.6.2, to support those users also.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 11, 2014 at 4:59 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>
>> For context and as a good example of how we could be less abrasive, I'm
>> unexpectedly spending today updating Hive with a bunch of new reflection
>> because methods in 1.5 on AccumuloInputFormat no longer exist in 1.7.
>> setZooKeeperInstance used to take two Strings, but in 1.7 this version of
>> the method was removed and forces client to use ClientConfiguration.
>>
>> This is a good example of where we didn't have to do this and there was
>> next to no maintenance support on us to preserve this method.
>>
>> Honestly, after writing this, I'm tempted to reinstate the old version
>> because doing this amount of reflection is painful and silly for clients
>> (and I even know what I'm doing most days!)
>>
>> Mike Drob wrote:
>>
>>> FWIW, Java 9 is dropping methods for the first time that the JDK API is
>>> dropping methods. Almost 20 years. Just something to consider, when we
>>> approach the conversation of how long to keep APIs around.
>>>
>>> On Thu, Dec 11, 2014 at 3:46 PM, Christopher<ctubbsii@apache.org>   wrote:
>>>
>>>   You seem to be dismissing "clean up" as an invalid. I disagree. There are
>>>> costs to keeping around deprecated APIs. That's not to say we shouldn't
>>>> keep them around for a long time... we can and perhaps should. But "clean
>>>> up" is just shorthand for all the maintainability, readability, and
>>>> usability costs. As such, I feel it incapsulates many reasons which are
>>>> sometimes difficult to express, but still valid.
>>>>
>>>> With semver in place, it seems like your position could be reduced to
>>>> "support major versions longer", which is a perfectly fine goal. As long
>>>> as
>>>> we have that, there's really no need to upgrade to the "latest", unless
>>>> there's a feature that you want which is difficult to backport in a minor
>>>> release. In that case, I think it's perfectly reasonable to consider the
>>>> risks of upgrading and to make the choice to upgrade and have the feature
>>>> or not upgrade and avoid API changes which affect you (if any).
>>>>
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>> On Thu, Dec 11, 2014 at 3:19 PM, Kepner, Jeremy - 0553 - MITLL<
>>>> kepner@ll.mit.edu>   wrote:
>>>>
>>>>   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