Thank you for clarifying your position. I had assumed from your response that you were -1 on the proposal when indeed you did not actually give an explicit -1. In that case, we will now move forward with the proposal to consider TO API v4 unstable until at least the three proposed breakages are completed as part of this next release cycle (roles & permissions, refetch invalidations, and layered profiles). After completing the upgrade to the version with these breaking changes, we will have a retrospective to determine if it was worth it and if it would be safe to do again in the future.
- Rawlin On Mon, Sep 13, 2021 at 6:48 PM Robert O Butts <r...@apache.org> wrote: > > > Again, this is a false statement. > > Every statement I have made in this thread is true to the best of my > knowledge. > > > @RobButts would you be willing to let us > > I am one individual, I have not voted -1 on this, and I have not in any way > suggested I will single-handedly push my agenda here against the consensus > of the community. If anyone believed otherwise, I apologize, that was never > my intent. > > I retract my previous comments, and recuse myself from the discussion and > decision on this thread. > > > On Thu, Sep 9, 2021 at 5:04 PM Rawlin Peters <raw...@apache.org> wrote: > > > > 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 is an interesting idea, but I think that would make the API more > > complex overall and wouldn't actually save us from a new major version > > in the long-run once we move the "unstable" section to the "response" > > section. Letting TO API 4.0 remain unstable for another release cycle > > allows us to keep the API simple (and make it simpler, really) while > > also not introducing a new major API version. > > > > @RobButts would you be willing to let us keep TO API 4.0 unstable for > > this upcoming release cycle and decide after if we should try it again > > in the future? > > > > - Rawlin > >