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 Tue, 02 Dec 2014 20:14:52 GMT
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
> 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.
>
>
Honestly, I don't expect us to have any major 1.x releases after 1.7.x.
These guidelines would just add some minor protection, making 1.x a bit
more stable in the transition to 2.0 if we ever do have such releases. I'd
hate for a user to seamlessly migrate to 2.0 from 1.7, but not be able to
seamlessly migrate from a 1.8 to 2.0, because 1.8 dropped some 1.7 API.


> 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+.
>
>
I believe I expressed that above, and only excluded things that were
deprecated prior to 1.7 (such as aggregators, which I expect to drop in
2.0).


> 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