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 16:40:36 GMT
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*.

Mime
View raw message