A module is at version 1.4.2. Two changes are ready: first, a fix for a wrong default tag value with no interface change, released on its own; second, renaming the input instance_size to instance_type. Following semantic versioning, which versions should the two releases carry?
Select an answer to reveal the explanation.
Short Explanation
Semantic versioning reads like a warning label: patch means you can relax, minor means new toys, major means something you rely on just changed. Renaming an input breaks every caller passing the old name, so it's a major release.
Full Explanation
Semantic versioning encodes compatibility in the version number: a patch increment signals backward-compatible bug fixes, a minor increment signals backward-compatible new functionality, and a major increment signals a breaking change to the public interface. Correcting a default tag value without changing inputs or outputs is a bug fix, so it moves 1.4.2 to 1.4.3. Renaming an input variable breaks every caller that passes the old name, because their module blocks now set an argument the module no longer declares, so the rename must be a major release, 2.0.0. Treating the rename as a minor release, whether 1.5.0 or 1.6.0, tells consumers using pessimistic constraints such as approximately 1.4 or approximately 1 that the upgrade is safe, and their plans then fail. Labeling the bug fix as a major version misinforms consumers in the other direction, forcing needless upgrade reviews for a harmless change, and leaves the subsequent breaking rename disguised as a minor bump. Exam caveat: a rename can be softened by keeping the old input deprecated for a release cycle, but the eventual removal is still a major version. Operational check: confirm that the release notes for 2.0.0 list the renamed input and the migration step, and that the registry shows both tags.