On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner <ke...@deenlo.com> wrote:
> > > On Thu, Dec 4, 2014 at 4:00 PM, John Vines <vi...@apache.org> wrote: > >> Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0. >> This is not something I encourage but I think this is something we should >> have in our pocket just in case. >> > > What do you think about the following? > > * API must be deprecated in 1.X release before it can be deprecated in > 2.0.0 > * Introduce new API in 1.8 w/ old API in deprecated form > * In 2.0.0 we drop old API > > This way we do not have the long lived support tail for the old API that I > think is one of your concerns. However this is still a nice bridge release > for users (one of my concerns). > To expand on this. Regarding John's point about bugs when supporting old and new API, it will would only get worse over time. The longer the old API is around not getting any attention from developers, the more likely it will start to break in subtle and unexpected ways. > > >> >> On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner <ke...@deenlo.com> wrote: >> >> > On Thu, Dec 4, 2014 at 12:59 PM, John Vines <vi...@apache.org> wrote: >> > >> > > On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner <ke...@deenlo.com> >> wrote: >> > > >> > > > 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? >> > > > >> > > >> > > That's great they're adjustable. I'm not going to agree to language >> now >> > > that I currently disagree with, especially language that may be >> difficult >> > > >> > >> > What language would you like to see? AFAICT you are advocating that any >> > committer should be able to freely drop undeprecated APIs in 2.0.0? >> > >> > >> > > to be amended. Not everyone seems to have an understanding of my >> concerns >> > > and the level of impact it has and that makes me question the ability >> to >> > > get a vote through to retract that portion of the language should it >> > arise. >> > > >> > >> > >
