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 Thu, 04 Dec 2014 00:04:47 GMT
On Wed, Dec 3, 2014 at 7:02 PM, Christopher <ctubbsii@apache.org> wrote:

> On Wed, Dec 3, 2014 at 6:48 PM, John Vines <vines@apache.org> wrote:
>
>> It's hard to track this down-
>> http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has
>> Busbey mentioning that 2.0 was breaking, which no one reacted to, implying
>> this was known
>>
>
> In that context, I had assumed he meant the dropping of deprecated APIs
> from previous releases.
>
>
>> http://www.mail-archive.com/dev%40accumulo.apache.org/msg08344.html has
>> Mike Drob stating this "In general, I'm inclined to leave as much in as
>> possible, and then if we
>>
>> must remove things then do so in 2.0.0. I know that our compatibility
>> statement only promises one minor version, but that doesn't mean we have
>> to
>> be strict at every opportunity." which promotes this idea.
>>
>>
> I believe we were talking about dropping deprecated stuff only here also.
>
>
>>
>> Christopher has a response to that which also corroborates the agreement.
>>
>>
>>
>> Though I feel the biggest reasoning is our switch to semantic
>> versioning. And from semver.org,
>>
>>
>>    1. MAJOR version when you make incompatible API changes
>>
>>
>> Which is exactly what we're talking about.
>>
>>
> Yes, but it is unclear *which* things to drop. From our current practice,
> it's clear that it would only be deprecated stuff in at least one minor
> version (same with Semver). The proposed guidelines here strengthen that
> (along the same lines as my DISCUSS thread on adopting Semver) such that we
> make fewer such drops.
>
> However, we're still talking about deprecated APIs only.
>

I don't read it that way


>
>
>>
>> On Wed, Dec 3, 2014 at 6:01 PM, Keith Turner <keith@deenlo.com> 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
>> >>
>> >
>> > Can you point me to where this consensus was reached?
>> >
>> >
>> >> 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.
>> >>
>> >> 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+.
>> >>
>> >> 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