It seems as if API v2.0 should be its own project.
On Thu, Dec 4, 2014 at 1:32 PM, Christopher <[email protected]> wrote: > 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
