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*.
