On Thu, Dec 4, 2014 at 11:30 AM, John Vines <vi...@apache.org> wrote:
> 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 > I feel like the logic behind this is as follows * Our API is user unfriendly in some ways, therefore lets create a new API thats more user friendly... * When we introduce the new user friendly API, lets do something thats really user unfiendly and completely drop the old API w/o warning (because many users are not following these discussions) > > > > > > > > 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 > > >>> > > > >>> > > >> > > >> > > > >
