On Wed, Feb 13, 2019 at 6:12 PM Robert Butts <[email protected]> wrote: > > >It doesn't seem like the idea of full TO API SemVer was ever fully > discussed and voted on > > >Since it seems like we never truly committed to SemVer with minor versions > for the TO API > > There was consensus: > https://lists.apache.org/thread.html/8f8a850c68424021a0fe06967894383a24e463f1b0cee4d652d04590@%3Cdev.trafficcontrol.apache.org%3E > https://lists.apache.org/thread.html/1a42a2192a81fc4d76639ccd10761b6b73c31345a63715bb8aa86e4e@%3Cdev.trafficcontrol.apache.org%3E > > We didn't do an official [VOTE], but we rarely do that as a project, unless > there's difficulty reaching unofficial consensus. That said, there's > nothing stopping another discussion or vote, if we want to change things.
I know, I read and linked to those threads in my original proposal, and I don't think there was ever a solid resolution to committing to SemVer with minor versions for the TO API. At the very least, there was no discussion of just committing to SemVer "major version only", which is what I'm proposing today for simplification of the TO API. The main issue that was brought up in those original threads was backwards compatibility in the API versions, since I'm assuming there were breaking changes made to the API which in turn broke some clients. At this point we are well aware that we should not be making breaking API changes without revving to v2, and I think we can agree that avoiding breaking changes within a major API version is much more important than ignoring and not returning new fields that didn't exist at a specific minor version. I've been trying really hard to avoid breaking changes within v1, but sometimes things slip through like the "Perl string numbers/bools" issue (which I think we should just accept and move on with). I'm not arguing against SemVer, just SemVer with minor versions. I think users can live without the "minor version promise", unless they start speaking up about what they really want. There's no point in enhancing the user experience if it's not bothering any users to see new fields in their responses. - Rawlin
