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 20:15:53 GMT
Sorry, another way to put this (more succinctly) is that I have removed
*all* deprecated APIs prior to 1.7 with the exception of the
instance.dfs.{uri,dir} configuration properties in my local 2.0 branch.
After some hindsight, essentially what I was trying to propose is that we
treat 1.7 as a "minor" release, and any subsequent 1.x releases as normal
"minor" or "patch" releases, according to definitions of those for Semver.

For the record, Semver also doesn't address what *should be* removed, only
what *can be*. If anybody wants to keep something around longer, I don't
consider that blocking these minimal guidelines. If we end up adopting
Semver, and apply the constraints to 1.7 moving forward, these proposed
guidelines are moot.



--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Wed, Dec 3, 2014 at 12:38 PM, Christopher <ctubbsii@apache.org> wrote:

> 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