The city’s permits API client library removes a response field that calling scripts previously required. Which semantic version bump should the maintainers publish?
Select an answer to reveal the explanation.
Short Explanation
SemVer’s MAJOR digit is the ‘breaking news’ headline on the city wire. Yank a field callers depended on, and you owe the next major number — not a quiet patch that pretends nothing broke.
Full Explanation
Semantic Versioning treats incompatible API changes as MAJOR bumps. When the city’s permits API client library removes a response field that calling scripts previously required, existing automation breaks at runtime or parse time. Publishing a new MAJOR version signals that consumers must adapt—update field usage, pin carefully, or schedule a coordinated cutover—rather than silently absorbing a breaking change under a patch-looking number.
A PATCH bump is reserved for backward-compatible bug fixes and documentation-only tweaks that do not remove required contract surface; field removal is not documentation. A MINOR bump covers backward-compatible additions; removals of required fields are not compatible. Claiming municipal APIs never follow SemVer ignores widely taught release hygiene and leaves callers without a machine-readable compatibility signal.
Exam caveat: if a field were purely additive or optional with safe defaults, MINOR might apply; the stem’s “previously required” language forces MAJOR. Operational check: bump major, publish a changelog noting the removed field, run consumer contract tests against the new major, and ensure the older major remains installable for lagging campus scripts during migration.