accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 15:10:35 GMT
On Tue, Dec 2, 2014 at 3:01 PM, Christopher <> 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).

This stmt can lead to disagreement later over what deprecated methods are
removed in 2.0.  We could explicitly list which deprecated methods will be
removed as part of this vote.  Alternatively, we could add a clause saying
there will be a vote prior to 2.0 over which methods are removed.  If we
decide now, then we could add something to 1.7.0 javadoc stating the method
will go away in 2.0.

I have been playing around w/ the following command to see whats currently
deprecated in master.

find core/src/main/java/org/apache/accumulo/core/client/ -name "*.java" |
grep -i -v impl | xargs grep Deprecated -C 3

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message