Description
A release is the moment a change stops being yours and becomes someone else's problem. Everything up to that point is about whether the change is good. From that point on it is about whether the people depending on you can tell what happened.
The awkward part is that your contract is not what you wrote down. With enough consumers, every observable behaviour of your system is depended on by somebody: error message formats, default ordering, timing, the quirk that was never intentional. So a change that breaks nothing you documented can still break them, and generation multiplies exactly this surface, because it produces more code paths and more incidental behaviour for somebody to come to rely on.
Meanwhile the receiving side has a fixed ceiling. Lehman observed that successive releases of a working system stay roughly constant in content, and explained it by the effort consumers need to absorb change rather than by anything on the producing side. Producers used to sense that ceiling and stop. Acceleration removed the sensing without moving the ceiling: people still read release notes at the speed they always did, and partner teams still update integrations on their own schedule.
Your consumers now include readers that cannot notice at all. Evaluations of code completion against libraries that had moved on find models writing calls that were already deprecated, and showing them the current interface does not reliably stop it. Which is why the honest test of this dimension is not whether you write release notes. It is whether the next time something breaks downstream, anybody inside your organisation knows before the customer's ticket arrives.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nothing tells anyone what changed. There is no changelog worth reading, no deprecation signal and no notice, so the people depending on your interfaces discover a change only when it breaks something for them. Detection happens outside your organisation, usually in a support ticket.
The tellTake your last downstream breakage and count how many people inside your organisation knew before the customer did. If the answer is zero, you are here.
- 2
Tacit
Communication happens through relationships. A team that knows who depends on it sends a message before a change lands, and the consumers who have a contact get warned. Anyone without that relationship, including a team two floors away, finds out only when something breaks.
The tellAsk who was told before your last interface change. If the list matches who happens to know your team socially, the communication is personal.
- 3
Visible but inert
Release notes exist and versions get bumped. The process is followed and the notes are written by people describing what they meant to change. Nothing checks the notes against what actually shipped, so an observable behaviour can move without appearing anywhere, and the version says compatible while the behaviour is not.
The tellCompare your last release notes against the actual diff. If a behaviour changed that the notes do not mention, the narrative is being maintained separately from the system.
- 4
Acted on
Change visibility is built into the running system rather than into a document. Deprecated paths announce themselves when used, a changed signature raises an alert, and consumers get told by the system they are calling rather than by a page they were supposed to read.
The tellFind the last deprecation you shipped. The runtime told the callers, and you can see who was still calling it, rather than the deprecation existing only in a document nobody read.
- 5
Durable
The signalling keeps up with how fast you now ship. Who depends on what is known rather than guessed, the impact of a change can be read before it is released, and the practice holds across new services rather than living on the two interfaces that once caused an incident.
The tellAsk who currently calls the interface you are about to change. If the system can answer before you ship, and it could answer for a service launched last month too, the visibility is durable.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Lehman, Programs, Life Cycles, and Laws of Software Evolution (Proceedings of the IEEE, 1980)
Observed that successive releases of a working system stay roughly constant in content, and explained it by the effort consumers need to absorb change. The ceiling is on the receiving side, which is the side acceleration does not touch.
Wang, Huang, Zhang, Feng, Zhang, Liu and Peng, LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-Based Code Completion (ICSE 2025)
Evaluated completions against libraries that had moved on, and found models writing calls that were already deprecated. Being shown the current interface did not reliably stop it, so consumers now include readers that cannot notice your change.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Release discipline →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.