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 22:12:45 GMT
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