I understand your point, Jonathan and Rob, but I think it is a bit much to assume that every upgrade of components that use the unstable API will break them entirely and cause a customer impact/outage. For the 3 things we're planning on breaking (jobs, users, servers), I'm pretty sure `t3c` is the only component truly affected that could potentially create bad ATS configs. Let's look at each in turn:
Jobs: If TO is upgraded first, `t3c` requests will get a 200, but it will just ignore the new field returned in the JSON, meaning jobs will still be "refresh" instead of "refetch." No impact here. If `t3c` is upgraded first, the new field will be empty, meaning `t3c` should just treat it as "refresh." No impact here either. Users: `t3c` does not use this API and will not be impacted. Servers: If TO is upgraded first, `t3c` requests will get a 200, but it will think all server profile IDs = 0 (because the field will be missing from the response, it will get unmarshalled as the int's "empty" value). `t3c` will then attempt to get parameters of profile 0 and get 404'd, causing the run to fail, leaving old configs in place. No real impact here other than not being able to change ATS configs until `t3c` is upgraded. If `t3c` is upgraded first, `t3c` requests will get a 200, but since the resulting profile arrays would be empty, it will cause the `t3c` run to fail, leaving old configs in place. Again, no real impact other than not being able to change ATS configs until TO is also upgraded. As you can see, this single coordinated upgrade would not cause any real impact. Would you at least be willing to try it out for the next release cycle in order to get these 3 breaking changes into API 4.0? That alone would be a major savings, and we'd only have to coordinate a single upgrade. - Rawlin