API version dropped while old app live: pre-release and first 30 minutes checklists

The backend removes an API version still used by installed app versions.

The pre-release checklist maps each item to a test class from the incident page. The first-30-minutes checklist covers detection, containment, the rollback decision and customer communication.

7 pre-release items · 7 first-30-minutes items · verified 2026-10-21

Pre-release checklist

PR-01Keep one contract test per client version still in distribution, including each old command-line release, and run all of them against the API before a version retirement takes effect. contract
PR-02Run the contract suite of every client pinned to the API version being retired against a staging environment with the retirement switched on, and block the retirement if any contract fails. contract
PR-03Add a contract test that pins the response a retired API version returns, so old clients receive a version-retired message and a minimum client version. contract
PR-04Query request logs for calls per API version before the end-of-life date and block the retirement config change while the retired version still receives requests. config
PR-05Confirm the end-of-life date for each API version is a configuration value that can be moved to a later date without a deploy. config
PR-06Schedule a production probe that calls the API with each oldest still-supported version and alerts on any HTTP 410 response. synthetic
PR-07Schedule a production check that runs the oldest still-distributed upload command-line version against the release upload endpoint and alerts on failure. synthetic

First 30 minutes

FM-01Group new errors and support tickets by client version and API version to confirm the failures come from old pinned versions.
FM-02Check whether a scheduled API version retirement or deprecation took effect at the start time, with no application deploy.
FM-03Search API logs for HTTP 410 responses stating that the requested API version is no longer available.
FM-04Decide whether to extend the end-of-life date through a configuration change or to restore the old endpoints temporarily.
FM-05Tell customers that failed operations can be retried once compatibility is restored.
FM-06Post a status update that names the affected API versions, the affected client versions and the new cut-off date.
FM-07Publish the minimum client versions customers must upgrade to before the new cut-off date.

Download the checklist

Pre-release checklist (Markdown)1.7 KB · v1.0.0
First 30 minutes checklist (Markdown)1.1 KB · v1.0.0

Only in this checklist

Every test class in this checklist also appears in at least one sibling checklist in the group; the item texts differ: Keep one contract test per client version still in distribution, including each old command-line release, and run all of them against the API before a version retirement takes effect.

Questions

What should be checked before a release to prevent API version dropped while old app live?

7 pre-release items, PR-01 to PR-07. PR-01: Keep one contract test per client version still in distribution, including each old command-line release, and run all of them against the API before a version retirement takes effect.

Is there a rollback plan for API version dropped while old app live?

The first-30-minutes checklist has 7 items. FM-01: Group new errors and support tickets by client version and API version to confirm the failures come from old pinned versions.

What should a team do in the first 30 minutes after API version dropped while old app live is detected?

The first-30-minutes checklist has 7 items. FM-01: Group new errors and support tickets by client version and API version to confirm the failures come from old pinned versions.

Which configuration checks apply to API version dropped while old app live?

PR-04: Query request logs for calls per API version before the end-of-life date and block the retirement config change while the retired version still receives requests. PR-05: Confirm the end-of-life date for each API version is a configuration value that can be moved to a later date without a deploy.

Is a API version dropped while old app live checklist still needed if deployment is automated?

Yes. Automation runs the steps; the checklist names what the tests must cover: contract tests, configuration and environment tests and synthetic monitoring.

Which pipeline stages does the API version dropped while old app live checklist cover?

The pre-release items map to the pre-merge, pre-deploy and post-deploy stages.