On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner <ke...@deenlo.com> wrote:
> 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) > > I'm concerned about the new API not being as user friendly because of the old API. And I would rather have a case of being extremely user unfriendly by removing the old API than having lost lasting implications of user unfriendliness by having plagued 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 > > > >>> > > > > >>> > > > >> > > > >> > > > > > > >
