On Thu, Dec 4, 2014 at 11:30 AM, John Vines <[email protected]> wrote:
> Sent from my phone, please pardon the typos and brevity. > On Dec 4, 2014 11:20 AM, "Keith Turner" <[email protected]> wrote: > > > > On Wed, Dec 3, 2014 at 6:48 PM, John Vines <[email protected]> wrote: > > > > > It's hard to track this down- > > > http://www.mail-archive.com/[email protected]/msg07336.html has > > > Busbey mentioning that 2.0 was breaking, which no one reacted to, > implying > > > this was known > > > http://www.mail-archive.com/dev%40accumulo.apache.org/msg08344.html > has > > > Mike Drob stating this "In general, I'm inclined to leave as much in as > > > possible, and then if we > > > > > > must remove things then do so in 2.0.0. I know that our compatibility > > > statement only promises one minor version, but that doesn't mean we > have to > > > be strict at every opportunity." which promotes this idea. > > > > > > > > > Christopher has a response to that which also corroborates the > agreement. > > > > > > > > > > > > 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 > > [snip] My position is that I think we can offer this guarantee, just as we've been doing with the most recent releases. At the very least, this is something that I'm willing to strive for, and discuss if we actually run into something that prevents us from (or overly burdens us) doing so. Until that point actually happens, I think backwards compatibility with 2.0 is something we should strive for. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
