Sent from my phone, please pardon the typos and brevity. On Dec 4, 2014 11:20 AM, "Keith Turner" <ke...@deenlo.com> wrote: > > On Wed, Dec 3, 2014 at 6:48 PM, John Vines <vi...@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 > > > > Which is exactly what we're talking about. > > > > > > On Wed, Dec 3, 2014 at 6:01 PM, Keith Turner <ke...@deenlo.com> wrote: > > > >> > >> > >> On Tue, Dec 2, 2014 at 3:07 PM, John Vines <vi...@apache.org> wrote: > >> > >>> -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions > >>> for > >>> the 2.0 API. We have already come to the consensus that 2.0 will break > >>> the > >>> 1.x API which provides a lot of breathing room and freedom from old > >>> > >> > >> Can you point me to where this consensus was reached? > >> > >> > >>> decisions. This causes this issue to come roaring back and an even larger > >>> amount of scrutiny to be required for all 1.7.0-1.9.9... API changes. I > >>> would go so far as to say an undefinable amount of scrutiny since we > >>> still > >>> don't have solid foundation of a 2.0 API. We cannot judge API items for > >>> how > >>> well they belong in an API that does not exist yet. > >>> > >>> Tangential- I would like to see a clause about all current API items will > >>> not be removed (still could be deprecated) until 2.0.0, as I feel this > >>> may > >>> ease some concerns about API alteration in 1.7+. > >>> > >>> On Tue, Dec 2, 2014 at 3:01 PM, Christopher <ctubb...@apache.org> wrote: > >>> > >>> > Following the conversation on the [VOTE] thread for ACCUMULO-3176, it > >>> seems > >>> > we require an explicit API guidelines at least for 1.7.0 and later > >>> until > >>> > 2.0.0. > >>> > > >>> > I hereby propose we adopt the following guidelines for future releases > >>> (if > >>> > we produce any such releases) until 2.0.0: > >>> > > >>> > API additions are permitted in "major" 1.x releases (1.7, 1.8, 1.9, > >>> 1.10, > >>> > etc.). > >>> > API should be forwards and backwards compatible within a 1.x release > >>> (no > >>> > new additions to the API in a "bugfix" release; e.g. 1.7.1). > >>> > New API in 1.7.0 and later 1.x releases will not be removed in 2.0 > >>> (though > >>> > they may be deprecated in 2.0 and subject to removal in 3.0). > >>> > Existing API in 1.7.0 will be preserved through 2.0, and should only be > >>> > subject to removal if it was already deprecated prior to 1.7.0 (though > >>> they > >>> > may be deprecated in 2.0 and subject to removal in 3.0). > >>> > > >>> > The purpose of these guidelines are to ensure the ability to add > >>> additional > >>> > functionality and evolve API naturally, while minimizing API > >>> disruptions to > >>> > the user base, in the interim before 2.0.0 when we can formally adopt > >>> an > >>> > API/versioning policy. > >>> > > >>> > Exceptions to these guidelines should be subject to a majority vote, > >>> on a > >>> > case-by-case basis. > >>> > > >>> > Because these relate to release planning, this vote will be subject to > >>> > majority vote, in accordance with our bylaws pertaining to release > >>> planning > >>> > and voting, and will be open for 3 days, concluding at 2000 on 5 Dec > >>> 2014 > >>> > UTC. > >>> > > >>> > -- > >>> > Christopher L Tubbs II > >>> > http://gravatar.com/ctubbsii > >>> > > >>> > >> > >> > >
