-1 Ditto, Bill; obligatory veto just because there was way too much
confusion and uncertainty. Although I generally liked what was proposed,
there's too much unrest within the rest of the community for me to +1 in
good conscience.
Bill Havanki wrote:
-1
The huge amount of discussion shows that the guidelines need to be updated
to reflect the general opinion and add specifics. Despite my vote, I think
it's great that all the discussion is happening. It should render a great
next set of guidelines.
On Tue, Dec 2, 2014 at 3:01 PM, Christopher<ctubb...@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
