On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner <[email protected]> wrote:
> > > On Thu, Dec 4, 2014 at 4:00 PM, John Vines <[email protected]> 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 > ooopppsss.. change "can be deprecated in 2.0.0" to "can be removed 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). > > >> >> On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner <[email protected]> wrote: >> >> > On Thu, Dec 4, 2014 at 12:59 PM, John Vines <[email protected]> wrote: >> > >> > > On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner <[email protected]> >> wrote: >> > > >> > > > On Thu, Dec 4, 2014 at 12:17 PM, John Vines <[email protected]> >> wrote: >> > > > >> > > > > On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser <[email protected] >> > >> > > > wrote: >> > > > > >> > > > > > John Vines wrote: >> > > > > > >> > > > > >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<[email protected] >> > >> > > > wrote: >> > > > > >> >> > > > > >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser< >> [email protected] >> > > >> > > > > >>> 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. >> > > >> > >> > >
