On Wed, Dec 3, 2014 at 7:02 PM, Christopher <ctubb...@apache.org> 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 >> > > In that context, I had assumed he meant the dropping of deprecated APIs > from previous releases. > > >> 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. >> >> > I believe we were talking about dropping deprecated stuff only here also. > > >> >> 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 >> >> >> Which is exactly what we're talking about. >> >> > Yes, but it is unclear *which* things to drop. From our current practice, > it's clear that it would only be deprecated stuff in at least one minor > version (same with Semver). The proposed guidelines here strengthen that > (along the same lines as my DISCUSS thread on adopting Semver) such that we > make fewer such drops. > > However, we're still talking about deprecated APIs only. > I don't read it that way > > >> >> 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 >> >> > >> >> >> > >> > >> > >
