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:39:48 GMT
On Thu, Dec 4, 2014 at 12:17 PM, John Vines <vines@apache.org> wrote:

> On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > John Vines 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.
> >>
> >
> > Sorry, Keith, you misinterpreted what I meant -- let me try to restate. I
> > am assuming that a new API will happen.
> >
> > What is only a possibility is that the old API implementation would
> > negatively affect the new API. John's concern is a hypothetical one that
> > isn't based on any *actual* implementation details. He's assuming that we
> > will hit some sort of roadblock which we would be unable to resolve in a
> > desirable way (a way that would not negatively impact 2.0 API).
> >
> > What I'm saying is that we should address those issues if and when we get
> > there. When we have context to a concrete problem, we can make a decision
> > there about how to proceed. Meanwhile, we act under best-intentions to
> keep
> > the 1.0 APIs around.
> >
> > Do you get what I'm suggesting, John?
> >
> >
> I'm totally okay with this. But that means no requirements about APIs from
> 1.x to 2.0. I'd be comfortable with changing the verbiage to something that
> lessens to encourage effort to support deprecated APIs so long as they
> don't influence 2.0 APIs.
>

One thing to consider is that the proposal has language for making
exceptions, a majority vote. What are your thoughts on that language?

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