accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 22:17:38 GMT
On Wed, Dec 3, 2014 at 4:41 PM, Christopher <ctubbsii@apache.org> wrote:

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

sounds good. I am ok w/ leaving that undefined and I like what the proposal
does define, its a massive improvement over what we have.  Changing vote to

+1

Removal of eligible deprecated methods would be subject to CTR and that
probably good enough for now.

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