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 18:22:26 GMT
-1 because I don't understand what is being proposed and it sounds like a
lot of other people do not either.

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.

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