accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 22:15:19 GMT
Does this information affect your vote?


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Tue, Dec 2, 2014 at 6:16 PM, Christopher <ctubbsii@apache.org> wrote:

> On Tue, Dec 2, 2014 at 5:18 PM, John Vines <vines@apache.org> wrote:
>
>> On Tue, Dec 2, 2014 at 3:14 PM, Christopher <ctubbsii@apache.org> wrote:
>>
>> > On Tue, Dec 2, 2014 at 3:07 PM, John Vines <vines@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 <ctubbsii@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
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message