I don't know that this would be "gaming it". It would actually represent the vanilla Semver standards, rather than the suggested modified version I suggested in the DISCUSS thread about Semantic Versioning. Semver only requires documenting a deprecation in at least one minor release, prior to dropping in the next major release. I had proposed a stronger stance: that we require documenting deprecation in at least one major release, before dropping in the next major after that. (See other thread).
If we did this, all it would mean would be that the version with the new client API would be called "1.8.0" instead of "2.0.0". It doesn't change the support duration for the old API... just what we call it. But, it sounds like your concerns are more for (hypothetical) problems which we might encounter trying to have both. And, those concerns would apply equally no matter what we call it. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec 4, 2014 at 5:16 PM, John Vines <vi...@apache.org> wrote: > I would be okay with a 1.8.0 FINAL (or 1.9 or 1.10 or whatever is the last > number of 1.x line) that exists solely for transitioning. It sounds a bit > like we're gaming it, but if that makes people more comfortable removing > backwards support in 2.0.0 than I'm okay with it. > > On Thu, Dec 4, 2014 at 5:12 PM, Keith Turner <ke...@deenlo.com> wrote: > > > > > > > On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner <ke...@deenlo.com> 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). > >> > > > > To expand on this. Regarding John's point about bugs when supporting > old > > and new API, it will would only get worse over time. The longer the old > > API is around not getting any attention from developers, the more likely > it > > will start to break in subtle and unexpected ways. > > > > > >> > >> > >>> > >>> 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. > >>> > > > >>> > > >>> > >> > >> > > >
