5 exercises — every developer reads and writes changelogs, migration guides, and release announcements. Identifying the correct version type shows you understand semantic versioning and breaking change principles.
Semantic versioning: MAJOR.MINOR.PATCH
MAJOR (5.0.0) — breaking change; existing code may stop working; requires migration
MINOR (3.2.0) — new backwards-compatible feature; existing code keeps working
Hotfix — emergency patch pushed outside the normal release cycle for a critical/security issue
0 / 5 completed
1 / 5
A changelog entry reads:
"v2.4.1 — Fixed a typo in the validation error message shown when an email address is too long."
What kind of version bump is this?
Patch version — the third number in semantic versioning (MAJOR.MINOR.PATCH). Patch releases fix bugs, typos, and other small issues. No new features are added. No existing behaviour breaks. Semver rule: increment PATCH when you make backwards-compatible bug fixes.
The three semver numbers in plain English: • MAJOR (2.x.x): Breaking change — existing code may stop working • MINOR (x.4.x): New feature — backwards compatible; nothing breaks • PATCH (x.x.1): Bug fix — backwards compatible; nothing new
A typo fix in a UI message does not add any new capability and does not break anything → it is a patch. "Hotfix" specifically means an emergency patch pushed directly to production outside the normal release cycle — it is a process distinction, not a version number category.
2 / 5
A library changelog states:
"v3.2.0 — Added a new optional retryConfig parameter to the createClient() function. Existing calls without this parameter continue to work as before."
What kind of version bump is this?
Minor version — a new feature or capability that is backwards compatible (existing integrations keep working without changes). Adding an optional parameter does not break any existing call sites. Semver rule: increment MINOR when you add functionality in a backwards-compatible manner.
Non-breaking vs. breaking changes — key distinction: • Adding an optional parameter → minor (non-breaking) • Adding a required parameter → major (breaking — all callers must update) • Changing a parameter type → major (breaking) • Removing a function → major (breaking) • Fixing a bug in an existing function → patch
The changelog phrase "existing calls without this parameter continue to work" is a signal that this is a non-breaking addition → minor.
3 / 5
A migration guide reads:
"v5.0.0 — The deprecated /api/v1/users endpoint has been removed. This endpoint was deprecated in v4.0 with a 12-month migration window. Please use /api/v2/users instead."
What kind of version bump is this?
Major version — any change that breaks backward compatibility requires a major version bump. Removing a public API endpoint, even one that was deprecated, means all clients still using /api/v1/users will get a 404 after upgrading. That is a breaking change → major. Semver rule: increment MAJOR when you make incompatible API changes.
Common breaking changes that require a major version: • Removing a public API endpoint, function, or method • Changing a function's return type or parameter types • Renaming a required configuration key • Changing the authentication mechanism • Removing or renaming a database column in a shared schema
The deprecation process in practice: deprecate in MINOR version (add @deprecated warning) → maintain for a set period → remove in next MAJOR version. The phrase "deprecated in v4.0 with a 12-month migration window" confirms this followed the standard process.
4 / 5
An engineering notice reads:
"URGENT — v2.8.4 released. This is an emergency release addressing CVE-2026-4412, a critical authentication bypass vulnerability in the session validation layer. All teams must upgrade immediately."
What kind of version bump is this?
Hotfix — an emergency release that goes directly to production, bypassing the normal development-staging-release cycle. Hotfixes are patches (they don't add features), but the term "hotfix" specifically refers to the urgency and process, not just the version bump category. Version number: patch-style increment (2.8.3 → 2.8.4).
When "hotfix" is used vs. "patch": • Patch: scheduled bug fix in the normal release cycle • Hotfix: emergency out-of-band fix, usually for P1/critical issues
Triggers for a hotfix: critical security vulnerability (CVE), data corruption bug, total service outage or regression, payment processing failure.
Hotfix workflow: branch from the current production tag (not from develop) → apply minimal fix → test → deploy → backport to develop/main. The signal words in this question are "URGENT", "emergency release", "CVE", and "must upgrade immediately".
5 / 5
A PR description reads:
"Internally rewrote the database connection pooling module from a custom implementation to HikariCP. All public API methods retain identical signatures — no interface changes. Performance improved by 40% under high load."
What kind of version bump is likely appropriate for this release?
Patch version — if the public API is identical (same method signatures, same behavior contract, same configuration keys) and no new user-visible features are added, an internal implementation swap is a patch-level change. In semver, what matters is the observable interface contract, not the internal implementation details. Semver rule: if no API changes and no new capabilities → patch.
Key phrase in the PR:"All public API methods retain identical signatures" — this is the decisive signal. From the consumer's perspective, nothing changes; the upgrade is transparent.
When an internal rewrite might require a minor or major bump: • If the new implementation adds new configuration options → minor • If the new implementation changes error types thrown → major (breaks error handling code) • If the new implementation removes a configuration key that existed before → major
In practice: teams sometimes bump minor for significant internal rewrites even if not strictly required by semver — to signal to users that thorough re-testing is advised.