accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 21:49:56 GMT
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