accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 16:57:55 GMT
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.

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