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 20:17:07 GMT
On Thu, Dec 4, 2014 at 1:22 PM, Mike Drob <madrob@cloudera.com> wrote:

> -1 because I don't understand what is being proposed and it sounds like a
> lot of other people do not either.
>

It would be nice if you could outline what you don't understand about the
original proposal.



>
> It looks like we've had several proposed amendments to the original
> proposal, but I am very unclear on if we are voting on any of them or if
> they are simply brought up as nice discussion points. There's been so much
> discussion in this VOTE thread (a strange complaint, I know) that I don't
> have a clear picture of what is up for decision any more.
> There has been so much negotiating and back and forth that I don't know
> which amendments are part of the vote, which ones are intended to be a
> follow on vote, and which ones are wild ideas that only a splinter group
> supports.
>

I think votes should only be considered as for or against the original
proposal, discussion can happen after someone votes.



>
> If we were to start a new vote on this, with all of the amendments rolled
> in to the opening message, then I would be happy to reconsider.
>
> On Thu, Dec 4, 2014 at 11:59 AM, 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
> > 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