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 16:30:45 GMT
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, "Keith Turner" <keith@deenlo.com> 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
> > 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.
> >
> >
> > 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
> >
> >
> >
> Right and dropping deprecated APIs is an incompatible change. Do you think
> the following two rules are reasonable?
>
>  * When API is deprecated, must offer replacement if feasible.
>  * Can only drop deprecated method when MAJOR version is incremented
(there
> are other proposed constraints on dropping deprecated methods)
>
> If we follow the above, then we can not deprecate current API before
> introducing new API (because the replacement would not exist
> concurrently).  Also we can not drop the current API in 2.0.0 if its not
> deprecated.

It is totally a reasonable statement for after 2.0.0. But for 2.0.0 I am
not okay making this guarantee because I would rather sacrifice backward
compatibility for an API that isn't plagued by shortcomings of the old API

>
>
> > Which is exactly what we're talking about.
> >
> >
> > 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