accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 19:39:29 GMT
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