+1 on deprecating API v2-3 with the release of ACTv6 and removing them in ATCv7. Hopefully we won't need a TO API v5 very soon so we can have a break from the API instability.
+1 on not requiring every v2 and v3 endpoint to return deprecation notices. I think just mentioning it on the mailing list, the changelog, and the docs should cover it. Updating all the v2/v3 endpoints to return deprecation notices would be quite a lot of code change with very little benefit IMO. However, for certain endpoints that have no v4 equivalent, we are returning deprecation notices (e.g. cachegroup parameters). - Rawlin On Fri, Jul 16, 2021 at 11:28 AM ocket 8888 <ocket8...@gmail.com> wrote: > > With the release of APIv4 in ATCv6, should we simultaneously deprecate > APIv2 and APIv3? I think so, that'll mean we can remove them in ATCv7, > whereupon the stable API 4.0 will have existed for a full major rev, and > APIv5 will ostensibly be released (if not sooner, since we could do that > e.g. in a 6.1). > > If so, we should also discuss what that will mean materially. With > endpoints that disappear between API versions we have them return > warning-level alerts that indicate they won't be available on upgrade, but > for APIv1 as a whole we didn't issue any kind of formal notice afaik, not > even a changelog entry. I think the right answer is somewhere between these > - a changelog entry and notices on the APIv2 and APIv3 reference sections > of the documentation. I don't think it's necessary to mention on each > endpoint that the entire API version is deprecated, either in the > documentation or in the API through Alerts.
