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 Thu, 04 Dec 2014 00:02:51 GMT
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.


>
> 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