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 17:38:13 GMT
On Wed, Dec 3, 2014 at 10:10 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).
> >
>
> 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.
>
>
These are intended to be minimal guidelines, not a comprehensive list of
what should be removed... only guidelines to ensure we don't remove
something in a breaking way. I'm fine with disagreeing with what can be
removed later... so long as we're agreed on certain minimal things which
cannot be removed, to ensure a smooth transition.

However, for the record, the comprehensive list of things I expect to
remove in 2.0, all of which were deprecated in 1.6.0 or prior:

Constants.NO_AUTHS (deprecated since 1.6.0)
ScannerOptions.{set,get}TimeOut(...) (deprecated since 1.5.0)
Connector.create[MultiTable]Batch{Deleter,Scanner}(...) without
BatchWriterConfig (deprecated since 1.5.0)
Instance.getConnector(...) that doesn't take an AuthorizationToken
(deprecated since 1.5.0)
MutationsRejectedException constructor (deprecated since 1.6.0)
MutationsRejectedException.getAuthorizationFailures() (deprecated since
1.5.0)
some ZooKeeperInstance constructors replaced with ClientConfiguration
(deprecated since 1.6.0)
some SecurityOperations methods (deprecated since 1.5.0)
TableOperations.getSplits() (deprecated since 1.5.0)
non-range TableOperations.flush() (deprecated since 1.4)
Constraint.getAuthorizations() (deprecated since 1.5.0)
static KeyExtent.getkeyExtentsForRange() (deprecated and unused utility
method)
Value constructor with copy param (deprecated and unused)
Aggregators (deprecated since 1.4)
protected Accumulo{Input,Output}Format.getToken[Class]() (deprecated since
1.6.0)
protected AccumuloInputFormat.getTabletLocator() (deprecated since 1.6.0)
protected AccumuloInputFormat.setupIterators() (deprecated since 1.5.0)
RangeInputSplit (deprecated since 1.5.2)

Additionally, I was going to remove the non-public API trace module
deprecated since 1.7 as part of the switch to HTrace.

I've actually already done this on my local 2.0 branch I'm working in, but
I have no intentions to remove anything else... and these guidelines would
effectively prevent me from doing so.

I would be opposed to adding javadocs stating methods will go away in 2.0,
unless they are already deprecated. The fact is... 2.0 is not available,
and we don't know exactly what will go away. But, we can establish
guidelines to give us an idea of what will not go away. That's the purpose
of the above guidelines.


> 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
> > http://gravatar.com/ctubbsii
> >
>

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