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 22:16:46 GMT
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