A municipal API platform vendor releases both a major version upgrade and a minor patch. What risk distinction should the change board expect?
Select an answer to reveal the explanation.
Short Explanation
A major upgrade is like swapping the whole bus model—riders may need new passes. A minor patch is more like fixing the windshield wipers without changing how you board.
Full Explanation
Semantic and platform versioning norms treat major upgrades as potentially breaking for clients and integrations, warranting deeper regression testing, while minor patches within a supported line are expected to remain compatible and lower risk. A municipal API platform change board should therefore expect different test depth, communication, and rollback planning for a major version upgrade versus a minor patch affecting citizen and agency consumers.
Treating major and minor updates as identical risk under-tests majors or over-burdens routine patches. Claiming minor patches always require rewriting every consuming application contradicts compatibility expectations. Assuming major upgrades never affect APIs if the DNS name stays the same ignores contract and payload breaking changes unrelated to DNS.
Exam caveat: provider versioning schemes vary; read release notes. "Major" vs "minor" is about compatibility risk, not merely the size of the binary. Deprecation timelines often accompany majors.
Operational check: classify the vendor release, run compatibility tests in non-prod for majors with representative municipal clients, stage minors with smoke tests, and publish consumer notices when breaking changes exist. Keep rollback images or pin policies ready before production promotion.