accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 16:40:06 GMT
On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner <keith@deenlo.com> wrote:

> On Thu, Dec 4, 2014 at 11:30 AM, John Vines <vines@apache.org> wrote:
>
> > Sent from my phone, please pardon the typos and brevity.
> > On Dec 4, 2014 11:20 AM, "Keith Turner" <keith@deenlo.com> wrote:
> > >
> > > On Wed, Dec 3, 2014 at 6:48 PM, John Vines <vines@apache.org> wrote:
> > >
> > > > It's hard to track this down-
> > > > http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html
> has
> > > > Busbey mentioning that 2.0 was breaking, which no one reacted to,
> > implying
> > > > this was known
> > > > http://www.mail-archive.com/dev%40accumulo.apache.org/msg08344.html
> > has
> > > > Mike Drob stating this "In general, I'm inclined to leave as much in
> as
> > > > possible, and then if we
> > > >
> > > > must remove things then do so in 2.0.0. I know that our compatibility
> > > > statement only promises one minor version, but that doesn't mean we
> > have to
> > > > be strict at every opportunity." which promotes this idea.
> > > >
> > > >
> > > > Christopher has a response to that which also corroborates the
> > agreement.
> > > >
> > > >
> > > >
> > > > Though I feel the biggest reasoning is our switch to semantic
> > versioning. And from semver.org,
> > > >
> > > >
> > > >    1. MAJOR version when you make incompatible API changes
> > > >
> > > >
> > > >
> > > Right and dropping deprecated APIs is an incompatible change. Do you
> > think
> > > the following two rules are reasonable?
> > >
> > >  * When API is deprecated, must offer replacement if feasible.
> > >  * Can only drop deprecated method when MAJOR version is incremented
> > (there
> > > are other proposed constraints on dropping deprecated methods)
> > >
> > > If we follow the above, then we can not deprecate current API before
> > > introducing new API (because the replacement would not exist
> > > concurrently).  Also we can not drop the current API in 2.0.0 if its
> not
> > > deprecated.
> >
> > It is totally a reasonable statement for after 2.0.0. But for 2.0.0 I am
> > not okay making this guarantee because I would rather sacrifice backward
> > compatibility for an API that isn't plagued by shortcomings of the old
> API
> >
>
> I feel like the logic behind this is as follows
>
>   * Our API is user unfriendly in some ways, therefore lets create a new
> API thats more user friendly...
>   * When we introduce the new user friendly API, lets do something thats
> really user unfiendly and completely drop the old API w/o warning (because
> many users are not following these discussions)
>
>
I'm concerned about the new API not being as user friendly because of the
old API. And I would rather have a case of being extremely user unfriendly
by removing the old API than having lost lasting implications of user
unfriendliness by having plagued API.


>
> >
> > >
> > >
> > > > Which is exactly what we're talking about.
> > > >
> > > >
> > > > On Wed, Dec 3, 2014 at 6:01 PM, Keith Turner <keith@deenlo.com>
> 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
> > > >>>
> > > >>
> > > >> Can you point me to where this consensus was reached?
> > > >>
> > > >>
> > > >>> 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.
> > > >>>
> > > >>> 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+.
> > > >>>
> > > >>> 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