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.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec 4, 2014 at 5:14 PM, Jeremy Kepner <kep...@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 <vi...@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 <ke...@deenlo.com> wrote: > > > > > > > On Thu, Dec 4, 2014 at 12:59 PM, John Vines <vi...@apache.org> > wrote: > > > > > > > > > On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner <ke...@deenlo.com> > > > wrote: > > > > > > > > > > > On Thu, Dec 4, 2014 at 12:17 PM, John Vines <vi...@apache.org> > > > wrote: > > > > > > > > > > > > > On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser < > josh.el...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > John Vines wrote: > > > > > > > > > > > > > > > >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner< > ke...@deenlo.com> > > > > > > wrote: > > > > > > > >> > > > > > > > >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser< > > > josh.el...@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. > > > > > > > > > > > > >
