On Thu, Dec 4, 2014 at 12:17 PM, John Vines <vi...@apache.org> wrote:
> On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser <josh.el...@gmail.com> wrote: > > > John Vines wrote: > > > >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<ke...@deenlo.com> wrote: > >> > >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser<josh.el...@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?
