accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 17:35:44 GMT
John Vines wrote:
> On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>
>> John Vines wrote:
>>
>>> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<keith@deenlo.com>   wrote:
>>>
>>>   On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser<josh.elser@gmail.com>
>>>> wrote:
>>>>
>>>>   John Vines wrote:
>>>>>   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
>>>>> Again, this is the fear/concern of impacting the new API due to
>>>>>
>>>> supporting
>>>>
>>>>> of the old which *may or may not even happen*.
>>>>>
>>>>>   Good point, we could adopt these rules now and never create a new
>>>> API.  I
>>>> think we would be better off adopting this now regardless of wether not
>>>> we
>>>> introduce a new API in the future.
>>>>
>>>> Also, if we do eventually create an API.  How is it user unfriendly to
>>>> have
>>>> the old API around in deprecated form?  The deprecation markings clearly
>>>> communicate that someone writing new code should not use the old API.
>>>> However it still allows existing code that users invested time into
>>>> writing
>>>> to run w/o issue against 2.0.0.
>>>>
>>>>
>>> I feel like I'm repeating myself. My concern is that the implementation
>>> details of maintaining the 1.x API in deprecated form will have a negative
>>> impact on the 2.0 API due to implementation details.
>>>
>> Sorry, Keith, you misinterpreted what I meant -- let me try to restate. I
>> am assuming that a new API will happen.
>>
>> What is only a possibility is that the old API implementation would
>> negatively affect the new API. John's concern is a hypothetical one that
>> isn't based on any *actual* implementation details. He's assuming that we
>> will hit some sort of roadblock which we would be unable to resolve in a
>> desirable way (a way that would not negatively impact 2.0 API).
>>
>> What I'm saying is that we should address those issues if and when we get
>> there. When we have context to a concrete problem, we can make a decision
>> there about how to proceed. Meanwhile, we act under best-intentions to keep
>> the 1.0 APIs around.
>>
>> Do you get what I'm suggesting, John?
>>
>>
> I'm totally okay with this. But that means no requirements about APIs from
> 1.x to 2.0. I'd be comfortable with changing the verbiage to something that
> lessens to encourage effort to support deprecated APIs so long as they
> don't influence 2.0 APIs.
>

Sean, does this approach satisfy your concerns (both original and below) 
WRT verbage and what has been outlined for technical direction for RPC 
layer compatibility issues?

Mime
View raw message