accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 22:28:41 GMT
I stand by my -1. This vote would guarantee a level of API compatibility
that I don't think we should be held to.

On Wed, Dec 3, 2014 at 5:15 PM, Christopher <ctubbsii@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 <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