# Governing Change — Routebase > Governance does not end at the first release. Which rules can check a change, what only a comparison between versions can tell you, and the alerts worth having. Canonical page: https://routebase.dev/guides/api-governance/governing-api-change/ Chapter 9 of 10 · API Governance · Last reviewed 2026-09-13 · The Routebase Team Everything so far governs a specification being written. Most of the risk in an API estate is in the specifications that already shipped and are still changing. ## What a rule can check about a change A rule reads one document, which limits what it can say about change. Within that limit there is still useful ground. It can check that a deprecated version carries a sunset date, which is the single most useful change-related rule there is. It can check that a published version has a readable alias, so consumers can say `v2` rather than quote a build number. It can check that the specification declares a versioning strategy at all, which is the thing teams skip and then improvise under pressure. Those are all questions about the current document, so a style guide handles them. They are also the paperwork rather than the risk. ## What only a comparison can tell you Whether a change breaks anybody depends on what the previous version promised, and no amount of reading the new document reveals that. Removing a field is a breaking change if something consumed it. Narrowing an enum breaks the caller sending the value you dropped. Making an optional request field required breaks everybody who omitted it. Each of those is invisible to a rule and obvious to a comparison, which is why the two mechanisms are complementary rather than alternatives. Run the comparison at the same gate as the rules, so a release produces one answer about both. [API breaking changes](/guides/api-versioning/api-breaking-changes/) covers the classification itself, and [backward compatible changes](/guides/api-versioning/backward-compatible-api-changes/) covers what you can ship without any of this. ## Alerts are the governance of things nobody is looking at A check runs when somebody does something. Alerts cover the state that develops when nobody does anything, and that is a different class of problem. Three are worth having. A spike of breaking changes in a single version usually means something was rewritten rather than evolved, and it is worth a conversation before release rather than after. A draft that has sat untouched for a month is either abandoned or blocked, and both are worth knowing. Changes that have been sitting unpublished for weeks mean the specification and what consumers can see have quietly diverged. None of these are violations. They are signals that a process stopped, which is exactly what a rules table cannot see. ## Deprecation is a governed process, not a label Marking a version deprecated is the easiest part and the least useful on its own. A deprecation that consumers should act on needs three things. It needs a date, because without one nothing follows from the label and people reasonably ignore it. It needs a successor, so the first question a consumer asks has an answer in the same place. It needs a migration path, even a short one, because the alternative is every consumer working out the same diff independently. The date is also what makes the process measurable. You can see whether traffic is moving off the old version in time, and a migration that has not started six weeks before the sunset is a decision you still have room to make. [Deprecation and sunset](/guides/api-versioning/api-deprecation-and-sunset/) covers the full sequence. ## In Routebase The change-related rules sit in the same guide as the rest, and the comparison and the alerts sit next to them. _Screenshot: A deprecation collects its sunset date, its successor and its migration guide before anything is announced, so the label always arrives with the answer to the next question._ A built-in rule flags a deprecated version without a sunset date, and further rules cover aliases on published versions and a configured versioning strategy. Version comparison reports what changed between two versions and marks the breaking entries, and the release flow surfaces them before a version is frozen. On the alerting side, breaking changes can raise an alert, and drafts left untouched beyond a configurable window raise one as well. Both sit on the governance settings page alongside the quality thresholds, so the process signals and the quality signals arrive through the same channel. The [Versioning](https://docs.routebase.dev/versioning/) guide covers deprecation, sunset dates and the release flow. ## Frequently asked questions ### How do you govern breaking changes to an API? With a comparison rather than a rule, because a breaking change is a relationship between two versions and a rule reads one document. Compare the candidate version against the one consumers are on, classify what changed, and require a decision on anything that removes or narrows something. The rules then cover the paperwork around it, such as whether a deprecated version carries a sunset date. ### Can a linter detect breaking API changes? Not on its own. A linter answers questions about the document in front of it, and whether a change breaks anybody depends entirely on what the previous version promised. A version comparison is the mechanism for that, and it is worth wiring into the same gate that runs your rules so both answers arrive together. ### What should happen when an API version is deprecated? The version should carry a sunset date, name its successor and say how to migrate before the announcement goes out. A deprecation without a date is a label, since nothing follows from it and consumers reasonably ignore it. The date is also what lets you tell the difference between a migration that is progressing and one that has stalled. --- [Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.