accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 18:58:22 GMT
It seems as if API v2.0 should be its own project.

On Thu, Dec 4, 2014 at 1:32 PM, Christopher <ctubbsii@apache.org> wrote:
> 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
View raw message