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.
