Practise semantic versioning vocabulary: MAJOR.MINOR.PATCH, pre-release suffixes, version bumping, and communicating breaking changes clearly in English.
0 / 5 completed
1 / 5
A library is at version 1.4.2. The team fixes a small bug without changing the public API. Which version should they release next?
Bug fixes that do not break the API increment the PATCH segment. 1.4.2 → 1.4.3. The MAJOR and MINOR segments remain unchanged because no new features were added and no existing behaviour was broken.
2 / 5
A developer says: 'We're adding a new optional method to the public interface — no existing code breaks.' Which version bump is correct?
New, backwards-compatible functionality increments the MINOR version. Existing code keeps working. MAJOR is only for breaking (incompatible) changes.
3 / 5
What does the suffix '-rc.1' mean in version '3.0.0-rc.1'?
'rc' stands for release candidate. 3.0.0-rc.1 is a pre-release version intended for testing. If no blockers are found, it is promoted to the stable 3.0.0. Pre-release versions have lower precedence than the release (3.0.0-rc.1 < 3.0.0).
4 / 5
A team member says 'this is a breaking change.' In the context of SemVer, this means they must:
Under Semantic Versioning, any change that breaks the public API contract requires a MAJOR version increment. This signals to consumers that they cannot upgrade without reviewing migration notes.
5 / 5
In a pull request description a developer writes: 'bumping the version to 2.1.0 for this release.' What action is being described?
'Bumping the version' means updating the version field (in package.json, setup.py, pom.xml, etc.) to the next version number. It is a routine step before cutting a release, often automated with tools like npm version or semantic-release.