Breaking change
A breaking change is a modification to an interface, behavior, format, configuration, or contract that can prevent existing consumers from working correctly without changes.
Automating API Delivery
A breaking change is an API modification that can cause existing consumers or integrations to stop working.
- How it is used
- Uses compatibility checks, versioning, and policy to manage API evolution for developers, product owners, and API consumers.
- How deep it goes
- Defines compatibility, enumerates OpenAPI cases, demonstrates oasdiff commands, and defers organization-specific classifications to published policy.
- Examples
- Uses endpoint removal, required request changes, schema tightening, enum changes, oasdiff output, and deprecated endpoint sunset.
- What you can do after
- Apply oasdiff checks to OpenAPI changes, interpret failures, and decide when versioning, coordination, or sunset policy is required.
Google Anthos in Action
A breaking change is a modification to an interface or behavior that can cause existing dependent clients or services to fail.
- How it is used
- Uses standard service contracts to identify changes that may affect dependent services during application modernization.
- How deep it goes
- Frames detection at the contract boundary without detailing compatibility rules or migration procedures.
- Examples
- Uses authentication, authorization, and logging as capabilities that teams can extract and rewrite incrementally.
- What you can do after
- Evaluate contract boundaries to identify changes that may affect dependent services during incremental modernization.
Go in Action, Second Edition
A breaking change is a modification that can prevent existing consumers from continuing to work without updates.
- How it is used
- Guides module release decisions and communicates whether consumers can adopt a version without updating their code.
- How deep it goes
- Defines SemVer impact categories and traces dependent go.mod updates, without detailing how to identify every incompatible API modification.
- Examples
- Uses domain/v0.0.1, a hypothetical domain/v2.0.0 transition, and independent api/v1.1.0 and worker/v1.1.0 Git tags.
- What you can do after
- Operate/configure Go module releases by selecting SemVer increments and updating dependent module requirements after incompatible changes.
Read how Go in Action, Second Edition explains breaking change →
Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu
A breaking change is a software change that makes previously valid code, configuration, or interfaces require modification to function correctly.
- How it is used
- Guides infrastructure teams in deciding when and how to change module interfaces without leaving users unprepared.
- How deep it goes
- Explains causes, batching, provider cascades, tests, and upgrade notes, but gives no detailed migration procedure beyond documenting interface changes.
- Examples
- Uses insecure defaults, renamed variables, provider requirements, removed deprecated features, major-release branches, and upgrade notes as examples.
- What you can do after
- Apply it by grouping compatible breaking changes, documenting migration instructions, branching major-release work, and using tests to detect regressions.
Building Web APIs with ASP.NET Core
A breaking change is a modification that can cause existing clients or system integrations to stop working correctly.
- How it is used
- Explains how API evolution can disrupt existing clients and how versioning can reduce immediate migration pressure.
- How deep it goes
- Defines common causes, describes parallel API versions, and evaluates complexity, security, and architectural trade-offs.
- Examples
- Uses regressions, interface modifications, type mismatches, vulnerable legacy endpoints, and simultaneous API versions as examples.
- What you can do after
- Evaluate whether API versioning adequately contains client disruption without creating unacceptable duplication, security exposure, or architectural constraints.
Read how Building Web APIs with ASP.NET Core explains breaking change →
Related concepts
- backward compatibilitycontrasts with · Backward compatibility is the property of a changed or newer system remaining usable by existing clients and consumers of its earlier interfaces, behavior, or data.
- versioningaddressed by · The practice of identifying and managing successive revisions of files, data, models, interfaces, or other artifacts so changes can be tracked and earlier states recovered.
- major versionproduces · A major version is the primary component of a version identifier that distinguishes a release line and commonly signals potentially backward-incompatible changes.
- review processaddressed by · A review process is a structured evaluation of work, performance, artifacts, or proposals against relevant criteria to assess quality, progress, correctness, or suitability.
- sunset strategyincludes · A sunset strategy is the planned discontinuation and shutdown of a software component, such as an API or subsystem, after its supported service period.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.