On Wed, Dec 3, 2014 at 5:28 PM, John Vines <vi...@apache.org> wrote: > I stand by my -1. This vote would guarantee a level of API compatibility > that I don't think we should be held to. >
Can you give some some specific reasons for your -1? > > On Wed, Dec 3, 2014 at 5:15 PM, Christopher <ctubb...@apache.org> wrote: > > > Does this information affect your vote? > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > On Tue, Dec 2, 2014 at 6:16 PM, Christopher <ctubb...@apache.org> wrote: > > > >> On Tue, Dec 2, 2014 at 5:18 PM, John Vines <vi...@apache.org> wrote: > >> > >>> On Tue, Dec 2, 2014 at 3:14 PM, Christopher <ctubb...@apache.org> > 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 > >>> > > 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. > >>> > > > >>> > > > >>> > Honestly, I don't expect us to have any major 1.x releases after > 1.7.x. > >>> > These guidelines would just add some minor protection, making 1.x a > bit > >>> > more stable in the transition to 2.0 if we ever do have such > releases. > >>> I'd > >>> > hate for a user to seamlessly migrate to 2.0 from 1.7, but not be > able > >>> to > >>> > seamlessly migrate from a 1.8 to 2.0, because 1.8 dropped some 1.7 > API. > >>> > > >>> > >>> This doesn't make any sense. I've been under the impression that there > >>> will > >>> not be a seamless migration to 2.0 from any release. I thought 2.0 was > >>> supposed to be a clean start of an API in order to prevent old method > >>> signatures from making a better, cleaner API. And with that, it means > >>> that > >>> migrating from 1.7 shouldn't make any different from 1.8. I expect > there > >>> to > >>> be no necessity for any api in any version of 1.x to exist in 2.0, > >>> including those introduced in 1.999.0 if that's what it takes. Your > >>> statement specifies differently and that either means my bases for > 2.0's > >>> API is false or your now introducing a new requirement to it. > >>> > >>> > >>> > >> We're not just going to drop the 1.x API. The core jar will still exist, > >> and contain all the old APIs (at least, that was my understanding). We > >> weren't going to throw out the window our normal practice of deprecating > >> APIs (I certainly had no intentions to do so). My understanding would be > >> that we would deprecate the old 1.x APIs in 2.0, and remove them in 3.0. > >> > >> I've not even considered this as a "new requirement" for the new client > >> API... it's just the way we do things in this community (deprecate > first, > >> remove later). The only difference would be that the version numbers > would > >> actually mean something in terms of guarantees about when we remove > those > >> deprecated methods. This is what I've consistently expressed in the > >> previous thread regarding ACCUMULO-3176. > >> > >> > >> > >>> > > >>> > > >>> > > 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+. > >>> > > > >>> > > > >>> > I believe I expressed that above, and only excluded things that were > >>> > deprecated prior to 1.7 (such as aggregators, which I expect to drop > in > >>> > 2.0). > >>> > > >>> > > >>> > > 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 > >>> > > > > >>> > > > >>> > > >>> > >> > >> > > >
