accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 22:33:17 GMT
On Wed, Dec 3, 2014 at 5:28 PM, John Vines <vines@apache.org> wrote:

> I stand by my -1. This vote would guarantee a level of API compatibility
> that I don't think we should be held to.
>

Can you give some some specific reasons for your -1?


>
> On Wed, Dec 3, 2014 at 5:15 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > Does this information affect your vote?
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Tue, Dec 2, 2014 at 6:16 PM, Christopher <ctubbsii@apache.org> wrote:
> >
> >> On Tue, Dec 2, 2014 at 5:18 PM, John Vines <vines@apache.org> wrote:
> >>
> >>> On Tue, Dec 2, 2014 at 3:14 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >>>
> >>> > 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.
> >>> >
> >>>
> >>> This doesn't make any sense. I've been under the impression that there
> >>> will
> >>> not be a seamless migration to 2.0 from any release. I thought 2.0 was
> >>> supposed to be a clean start of an API in order to prevent old method
> >>> signatures from making a better, cleaner API. And with that, it means
> >>> that
> >>> migrating from 1.7 shouldn't make any different from 1.8. I expect
> there
> >>> to
> >>> be no necessity for any api in any version of 1.x to exist in 2.0,
> >>> including those introduced in 1.999.0 if that's what it takes. Your
> >>> statement specifies differently and that either means my bases for
> 2.0's
> >>> API is false or your now introducing a new requirement to it.
> >>>
> >>>
> >>>
> >> We're not just going to drop the 1.x API. The core jar will still exist,
> >> and contain all the old APIs (at least, that was my understanding). We
> >> weren't going to throw out the window our normal practice of deprecating
> >> APIs (I certainly had no intentions to do so). My understanding would be
> >> that we would deprecate the old 1.x APIs in 2.0, and remove them in 3.0.
> >>
> >> I've not even considered this as a "new requirement" for the new client
> >> API... it's just the way we do things in this community (deprecate
> first,
> >> remove later). The only difference would be that the version numbers
> would
> >> actually mean something in terms of guarantees about when we remove
> those
> >> deprecated methods. This is what I've consistently expressed in the
> >> previous thread regarding ACCUMULO-3176.
> >>
> >>
> >>
> >>> >
> >>> >
> >>> > > 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