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?
