Increment Major Version vs. Deprecation Message: Choosing a NuGet Strategy for Safe Rollback After a Breaking Schema Change

The goal is to allow consumers of a NuGet package to revert to a non‑breaking version after a breaking schema change without having to manually edit version constraints in their project or lock files. NuGet treats each published version as immutable, so rollback depends entirely on the consumer’s version range and any lock‑file constraints. The documented options are to increment the major version (following SemVer) and optionally unlist the old version, or to keep the same ID and version while adding a deprecation message and relying on consumers to exclude the breaking version via version ranges.

Because unlisted versions remain in local caches and broad ranges can still pull the breaking version, it is unclear which approach provides a more reliable safety net for rollback, especially when teams use lock files or continuous integration pipelines that restore from cached packages. This uncertainty raises questions about the trade‑off between explicit version bumps and deprecation messaging for ensuring that a rollback to a safe version is both discoverable and enforceable. Which strategy better prevents accidental restoration of a breaking version when local caches are present? How does each approach interact with lock‑file‑based restores to guarantee that a consumer can revert to a prior safe version without manual intervention?