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 23:57:10 GMT
On Wed, Dec 3, 2014 at 5:28 PM, John Vines <vines@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.
>
>
So, this degree of compatibility is our *current* practice between major
versions, and this is the default assumption I've been operating under.
These proposed guidelines do not presume to add that requirement... they
only assumes our current practice of API support between major releases
(something I feel we've consistently been getting better at since 1.5).

Whether we should discard this current practice for 2.0 seems like a
separate conversation (though it may be a prerequisite for this vote), and
I'm not sure where the idea that developers would be on board with this
came from (a misunderstanding in a previous thread, perhaps?). Personally,
I would vote against discarding the current practice, because I think it's
a bad idea to introduce breaking changes without deprecating first, and
giving users some opportunity to migrate at their own pace when they
upgrade.

This (mis?)understanding seems to be at the heart of a lot of the dialogue
on this list in the past few weeks. If you could direct me to some previous
thread which established consensus on the decision to discard the 1.x APIs
without deprecated support, I think it would help.


> 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