On Thu, Dec 4, 2014 at 11:57 AM, John Vines <[email protected]> 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. > Thanks for repeating yourself, because I missed that concern. Its hard to follow this thread. Thats a valid concern. By trying to support both, its certainly possible that we end up with more bugs as a result which negatively impacts user experience. I think that possibility becoming a worst case reality depends on the strategy used to implement the new API (maximizing code resuse, testing strategy). Having both will cause some bugs, but hopefully we can follow a strategy that minimizes bugs and maintenance cost. You have made me very interested in knowing what this strategy is :)
