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 21:37:39 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
>


ooopppsss.. change "can be deprecated in 2.0.0" to "can be removed 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).
>
>
>>
>> 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