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 Fri, 05 Dec 2014 17:04:03 GMT
On Fri, Dec 5, 2014 at 11:35 AM, Christopher <ctubbsii@apache.org> wrote:

> The version name has nothing to do with when we remove deprecated APIs...
> only what we call it when we do.
> I agree that removing undeprecated APIs is a nonstarter.
>

I also agree.  I think for this case someone should have to articulate
their reasons for dropping an undeprecated method and put it up for a
vote.    I think vines has brought up a good example for when this could
possibly occur, but that depends on particulars that may never come to be.


>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 5:14 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:
>
> > So I feel the opposite.  I think we shouldn't remove deprecated APIs
> > unless they absolutely break the system.  I think removing any
> > undeprecated APIs is a non-starter.
> > As a person who has to oversee hundreds of Accumulo instances with many
> > users writing many programs,
> > I really want to be able to upgrade my Accumulo instances without
> > having to worry about breaking my users programs.  Every time any
> function
> > is removed that means I am stuck supporting that version of Accumulo
> > forever and having systems that can never be upgraded.
> >
> >
> > On Thu, Dec 04, 2014 at 04:36:10PM -0500, Keith Turner 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).
> > >
> > >
> > > >
> > > > 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