accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 22:14:51 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message