accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 17:12:59 GMT
On Thu, Dec 4, 2014 at 11:57 AM, John Vines <vines@apache.org> wrote:

> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner <keith@deenlo.com> wrote:
>
> > On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser <josh.elser@gmail.com>
> wrote:
> >
> > > John Vines wrote:
> > >
> > >> Though I feel the biggest reasoning is our switch to semantic
> > >>>>
> > >>> versioning. And from semver.org,
> > >>
> > >>> >  >
> > >>>> >  >
> > >>>> >  >      1. MAJOR version when you make incompatible API
changes
> > >>>> >  >
> > >>>> >  >
> > >>>> >  >
> > >>>>
> > >>> >  Right and dropping deprecated APIs is an incompatible change.
Do
> you
> > >>> think
> > >>> >  the following two rules are reasonable?
> > >>> >
> > >>> >    * When API is deprecated, must offer replacement if feasible.
> > >>> >    * Can only drop deprecated method when MAJOR version is
> > incremented
> > >>>
> > >> (there
> > >>
> > >>> >  are other proposed constraints on dropping deprecated methods)
> > >>> >
> > >>> >  If we follow the above, then we can not deprecate current API
> before
> > >>> >  introducing new API (because the replacement would not exist
> > >>> >  concurrently).  Also we can not drop the current API in 2.0.0
if
> its
> > >>> not
> > >>> >  deprecated.
> > >>>
> > >>
> > >> It is totally a reasonable statement for after 2.0.0. But for 2.0.0 I
> am
> > >> not okay making this guarantee because I would rather sacrifice
> backward
> > >> compatibility for an API that isn't plagued by shortcomings of the old
> > API
> > >>
> > >
> > > Again, this is the fear/concern of impacting the new API due to
> > supporting
> > > of the old which *may or may not even happen*.
> > >
> >
> > Good point, we could adopt these rules now and never create a new API.  I
> > think we would be better off adopting this now regardless of wether not
> we
> > introduce a new API in the future.
> >
> > Also, if we do eventually create an API.  How is it user unfriendly to
> have
> > the old API around in deprecated form?  The deprecation markings clearly
> > communicate that someone writing new code should not use the old API.
> > However it still allows existing code that users invested time into
> writing
> > to run w/o issue against 2.0.0.
> >
>
> I feel like I'm repeating myself. My concern is that the implementation
> details of maintaining the 1.x API in deprecated form will have a negative
> impact on the 2.0 API due to implementation details.
>

Thanks for repeating yourself, because I missed that concern.  Its hard to
follow this thread.

Thats a valid concern. By trying to support both, its certainly possible
that we end up with more bugs as a result which negatively impacts user
experience.  I think that possibility becoming a worst case reality depends
on the strategy used to implement the new API (maximizing code resuse,
testing strategy).   Having both will cause some bugs, but hopefully we can
follow a strategy that minimizes bugs and maintenance cost.   You have made
me very interested in knowing what this strategy is :)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message