accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 18:32:25 GMT
On Thu, Dec 4, 2014 at 11:30 AM, John Vines <vines@apache.org> wrote:

> Sent from my phone, please pardon the typos and brevity.
> On Dec 4, 2014 11:20 AM, "Keith Turner" <keith@deenlo.com> wrote:
> >
> > On Wed, Dec 3, 2014 at 6:48 PM, John Vines <vines@apache.org> wrote:
> >
> > > It's hard to track this down-
> > > http://www.mail-archive.com/dev@accumulo.apache.org/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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message