Yeah, Jonathan hit the nail on the head, there are some specific things coming that we know are breaking changes, and it would be nice to add those to 4.0 instead of having to roll yet another API version before 4.0 is even released. I am +1 with doing this just for 4.0 and then retrospecting after.
Not to keep the can of worms open, but could a happy medium an alternative here be to add a new section to our API responses at the same level as "response" that we could add new/breaking stuff to in the current API version? That way, clients that don't need or know about the new breaking thing could just use the `response` section which is stable and new clients can use the `unreleased` (or whatever) section? It's just json so everytime you need to change it you can just add a new field under unreleased and then once a feature/whatever is stable and we are ready to make a new API version, we just move stuff from `unreleased` up to `response`? Just a thought, trying to come up with something that allows us to iterate quickly without potentially causing customer issues and/or getting ourselves in a situation where upgrades are broken. --Dave On Wed, Sep 8, 2021 at 3:40 PM Rawlin Peters <raw...@apache.org> wrote: > > It seems you have a very specific set of goals with this proposal rather > than a general practice here, and possibly a very limited duration for this > proposal > > I would still love to see this implemented as a general practice (new > API versions being considered unstable until officially stabilized), > but I'm willing to concede that we just try it out for a release cycle > (specifically for the 3 breaking changes we have planned) before > having a retrospective to determine if it was a successful practice or > not and whether or not we should continue with it. Even if we choose > not to continue the practice, we'll still have saved ourselves from > the pain of having yet another major TO API version. > > - Rawlin >
