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 21:41:32 GMT
On Wed, Dec 3, 2014 at 10:31 AM, Keith Turner <keith@deenlo.com> wrote:

> 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).
> >
>
> -1 For the reason I stated earlier.  I think we are setting ourselves to
> waste time in the future debating this by not making a more firm decision
> now about which deprecated methods will be dropped.  In the earlier email I
> listed two options, are there other options?
>
>
To clarify that last line, starting with "Existing API": when I say "should
only be subject to removal if it was already deprecated prior to 1.7.0",
what I mean to do is clarify which things are possible to consider for
removal: existing API will not be considered for removal; API deprecated
prior to that could be considered for removal. I do not intend to suggest
that these "must be" removed, or that they "should be" removed, or that
agreement with these guidelines is the same as agreement with any specific
removal. My only intention here was to define the scope of things which are
subject to the removal consideration process and which are not, to ensure
stability.

The specific subset of "can be considered for removal" category is not
defined here, and is outside the scope of these guidelines. These
guidelines, as proposed, should be interpreted to be compatible with
removing all these things in this category, or preserving all of them, or
anywhere in between. The only thing I intend these guidelines to establish
is which things must not be removed, for the sake of backwards
compatibility/API stability guarantees.


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