accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 20:28:08 GMT
On Thu, Dec 4, 2014 at 2:17 PM, Keith Turner <keith@deenlo.com> wrote:

> 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.
>
> There have been 80 emails on this thread. I do not understand which
proposed amendments from this thread apply to the vote and which do not.

>
>
> >
> > 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.
>
> Sounds like you're saying that none of them apply. That's fine. In that
case:

-1. The language in the initial proposal is vague and imprecise.

Mechanically, where do we apply these guidelines? Are these changes to our
governance model?

Why are we forcing ourselves to commit to the 1.7 API in 2.0, if there is a
1.8 that deprecates things? What is so special about 1.7 at all?

I agree with John's concerns.

I don't think that we can make practical progress on this issue until we
have a real proposal in hand. I'd rather not speculate and vote about
hypothetical APIs.



>
> >
> > 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