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 Fri, 05 Dec 2014 16:34:07 GMT
I don't know that this would be "gaming it". It would actually represent
the vanilla Semver standards, rather than the suggested modified version I
suggested in the DISCUSS thread about Semantic Versioning. Semver only
requires documenting a deprecation in at least one minor release, prior to
dropping in the next major release. I had proposed a stronger stance: that
we require documenting deprecation in at least one major release, before
dropping in the next major after that. (See other thread).


If we did this, all it would mean would be that the version with the new
client API would be called "1.8.0" instead of "2.0.0". It doesn't change
the support duration for the old API... just what we call it. But, it
sounds like your concerns are more for (hypothetical) problems which we
might encounter trying to have both. And, those concerns would apply
equally no matter what we call it.


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

On Thu, Dec 4, 2014 at 5:16 PM, John Vines <vines@apache.org> wrote:

> I would be okay with a 1.8.0 FINAL (or 1.9 or 1.10 or whatever is the last
> number of 1.x line) that exists solely for transitioning. It sounds a bit
> like we're gaming it, but if that makes people more comfortable removing
> backwards support in 2.0.0 than I'm okay with it.
>
> On Thu, Dec 4, 2014 at 5:12 PM, Keith Turner <keith@deenlo.com> wrote:
>
> >
> >
> > On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner <keith@deenlo.com> wrote:
> >
> >>
> >>
> >> On Thu, Dec 4, 2014 at 4:00 PM, John Vines <vines@apache.org> wrote:
> >>
> >>> Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
> >>> This is not something I encourage but I think this is something we
> should
> >>> have in our pocket just in case.
> >>>
> >>
> >> What do you think about the following?
> >>
> >>   * API must be deprecated in 1.X release before it can be deprecated in
> >> 2.0.0
> >>   * Introduce new API in 1.8 w/ old API in deprecated form
> >>   * In 2.0.0 we drop old API
> >>
> >> This way we do not have the long lived support tail for the old API that
> >> I think is one of your concerns.  However this is still a nice bridge
> >> release for users (one of my concerns).
> >>
> >
> > To expand on this.   Regarding John's point about bugs when supporting
> old
> > and new API, it will would only get worse over time.  The longer the old
> > API is around not getting any attention from developers, the more likely
> it
> > will start to break in subtle and unexpected ways.
> >
> >
> >>
> >>
> >>>
> >>> On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner <keith@deenlo.com> wrote:
> >>>
> >>> > On Thu, Dec 4, 2014 at 12:59 PM, John Vines <vines@apache.org>
> wrote:
> >>> >
> >>> > > On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner <keith@deenlo.com>
> >>> wrote:
> >>> > >
> >>> > > > On Thu, Dec 4, 2014 at 12:17 PM, John Vines <vines@apache.org>
> >>> wrote:
> >>> > > >
> >>> > > > > On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser <
> >>> josh.elser@gmail.com>
> >>> > > > wrote:
> >>> > > > >
> >>> > > > > > John Vines wrote:
> >>> > > > > >
> >>> > > > > >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<
> >>> keith@deenlo.com>
> >>> > > > wrote:
> >>> > > > > >>
> >>> > > > > >>  On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser<
> >>> josh.elser@gmail.com
> >>> > >
> >>> > > > > >>> wrote:
> >>> > > > > >>>
> >>> > > > > >>>  John Vines wrote:
> >>> > > > > >>>>
> >>> > > > > >>>>  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
> >>> > > > > >>>
> >>> > > > > >>>> Again, this is the fear/concern of
impacting the new API
> >>> due to
> >>> > > > > >>>>
> >>> > > > > >>> supporting
> >>> > > > > >>>
> >>> > > > > >>>> of the old which *may or may not even
happen*.
> >>> > > > > >>>>
> >>> > > > > >>>>  Good point, we could adopt these rules
now and never
> >>> create a
> >>> > new
> >>> > > > > >>> API.  I
> >>> > > > > >>> think we would be better off adopting this
now regardless
> of
> >>> > wether
> >>> > > > not
> >>> > > > > >>> we
> >>> > > > > >>> introduce a new API in the future.
> >>> > > > > >>>
> >>> > > > > >>> Also, if we do eventually create an API.
 How is it user
> >>> > unfriendly
> >>> > > > to
> >>> > > > > >>> have
> >>> > > > > >>> the old API around in deprecated form?
 The deprecation
> >>> markings
> >>> > > > > clearly
> >>> > > > > >>> communicate that someone writing new code
should not use
> the
> >>> old
> >>> > > API.
> >>> > > > > >>> However it still allows existing code that
users invested
> >>> time
> >>> > into
> >>> > > > > >>> writing
> >>> > > > > >>> to run w/o issue against 2.0.0.
> >>> > > > > >>>
> >>> > > > > >>>
> >>> > > > > >> I feel like I'm repeating myself. My concern
is that the
> >>> > > > implementation
> >>> > > > > >> details of maintaining the 1.x API in deprecated
form will
> >>> have a
> >>> > > > > negative
> >>> > > > > >> impact on the 2.0 API due to implementation
details.
> >>> > > > > >>
> >>> > > > > >
> >>> > > > > > Sorry, Keith, you misinterpreted what I meant --
let me try
> to
> >>> > > > restate. I
> >>> > > > > > am assuming that a new API will happen.
> >>> > > > > >
> >>> > > > > > What is only a possibility is that the old API
implementation
> >>> would
> >>> > > > > > negatively affect the new API. John's concern is
a
> >>> hypothetical one
> >>> > > > that
> >>> > > > > > isn't based on any *actual* implementation details.
He's
> >>> assuming
> >>> > > that
> >>> > > > we
> >>> > > > > > will hit some sort of roadblock which we would
be unable to
> >>> resolve
> >>> > > in
> >>> > > > a
> >>> > > > > > desirable way (a way that would not negatively
impact 2.0
> API).
> >>> > > > > >
> >>> > > > > > What I'm saying is that we should address those
issues if and
> >>> when
> >>> > we
> >>> > > > get
> >>> > > > > > there. When we have context to a concrete problem,
we can
> make
> >>> a
> >>> > > > decision
> >>> > > > > > there about how to proceed. Meanwhile, we act under
> >>> best-intentions
> >>> > > to
> >>> > > > > keep
> >>> > > > > > the 1.0 APIs around.
> >>> > > > > >
> >>> > > > > > Do you get what I'm suggesting, John?
> >>> > > > > >
> >>> > > > > >
> >>> > > > > I'm totally okay with this. But that means no requirements
> about
> >>> APIs
> >>> > > > from
> >>> > > > > 1.x to 2.0. I'd be comfortable with changing the verbiage
to
> >>> > something
> >>> > > > that
> >>> > > > > lessens to encourage effort to support deprecated APIs
so long
> as
> >>> > they
> >>> > > > > don't influence 2.0 APIs.
> >>> > > > >
> >>> > > >
> >>> > > > One thing to consider is that the proposal has language for
> making
> >>> > > > exceptions, a majority vote. What are your thoughts on that
> >>> language?
> >>> > > >
> >>> > >
> >>> > > That's great they're adjustable. I'm not going to agree to language
> >>> now
> >>> > > that I currently disagree with, especially language that may be
> >>> difficult
> >>> > >
> >>> >
> >>> > What language would you like to see?  AFAICT you are advocating that
> >>> any
> >>> > committer should be able to freely drop undeprecated APIs in 2.0.0?
> >>> >
> >>> >
> >>> > > to be amended. Not everyone seems to have an understanding of
my
> >>> concerns
> >>> > > and the level of impact it has and that makes me question the
> >>> ability to
> >>> > > get a vote through to retract that portion of the language should
> it
> >>> > arise.
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>

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