I would be okay with a 1.8.0 FINAL (or 1.9 or 1.10 or whatever is the last number of 1.x line) that exists solely for transitioning. It sounds a bit like we're gaming it, but if that makes people more comfortable removing backwards support in 2.0.0 than I'm okay with it.
On Thu, Dec 4, 2014 at 5:12 PM, Keith Turner <ke...@deenlo.com> wrote: > > > 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. >>> > > >>> > >>> >> >> >
