accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 19:26:05 GMT
I have never said we shouldn't strive for it. I am saying having a good 2.0
api is more important than that. And by putting in requirements about how
1.x APIs appear in 2.x I feel we are leaving us unable to enforce my
preferred ordering of priorities.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message