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.
