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 23:58:19 GMT
I already cited sources for it in my previous response.

On Wed, Dec 3, 2014 at 6:57 PM, Christopher <ctubbsii@apache.org> wrote:

> 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