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 Thu, 04 Dec 2014 16:34:13 GMT
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)


>
> >
> >
> > > 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