LTS = Long-Term Support (extended maintenance window)
0 / 10 completed
1 / 10
How do you read the version number v3.0.0 aloud in English?
Reading semver numbers aloud Software version numbers follow Semantic Versioning (semver): MAJOR.MINOR.PATCH. Native English speakers typically use "point" or "dot" as the separator:
✅ "version three point zero point zero" (most common in speech) ✅ "version three dot zero dot zero" (also acceptable) ✅ In informal speech: just "v three" or "version three" when context is clear
More examples: • v2.14.1 → "version two point fourteen point one" • v1.0.0-beta → "version one point zero point zero beta" • v22.5.3 → "version twenty-two point five point three"
When writing in documents: always use the "v" prefix: v3.0.0. In speech, you can drop it: "Are you on three point zero?" The zeros are still read individually, not as "three hundred" or "third."
2 / 10
A teammate says: "I merged a minor update — I added an OAuth login feature." According to Semantic Versioning (semver), is "minor" the right term for adding a new feature?
Semantic Versioning (semver) — MAJOR.MINOR.PATCH Semver is the standard versioning system for software libraries, APIs, and packages. Each segment has a specific meaning:
PATCH (e.g., 2.3.1 → 2.3.2): Bug fixes. No new features. Backwards-compatible. "We patched the edge case in the parser."
MINOR (e.g., 2.3.0 → 2.4.0): New features added in a backwards-compatible way. Existing users' code still works. "We released a minor version with the new OAuth endpoint."
MAJOR (e.g., 2.0.0 → 3.0.0): Breaking changes. Existing code may stop working. Requires migration. "v3 is a major release — clients must update their integration."
In the question: OAuth login is new functionality added without breaking existing integrations → MINOR bump is correct.
Rule of thumb: If users need to change their code to upgrade → MAJOR. If users get new things for free → MINOR. If you just fixed a bug → PATCH.
3 / 10
A release is labeled v2.0.0-rc.2. How do you say this aloud, and what does it mean?
Release candidate (RC) — the final pre-release stage The -rc.2 suffix is a semver pre-release identifier. Here's how to read and understand it:
Reading aloud: "version two point zero point zero release candidate two"
What it means: A release candidate is a build that the team believes is ready for production, but is being put through final validation before the official stable release. "RC2" means this is the second release candidate — RC1 had issues that were fixed.
Common pre-release identifiers in order (least stable → most stable): • -alpha.1 — early internal testing, unstable, many features missing • -beta.1 — feature-complete but with known bugs, broader testing • -rc.1 — release candidate, final testing phase, should be stable • (no suffix) — stable, production-ready release
Stability order in semver:1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0
In conversation: "We're on RC2 — if no critical bugs come in this week, we ship Friday."
4 / 10
Your team is planning to switch from Node.js 20 to Node.js 22 LTS. What does "LTS" mean, and why does it matter?
LTS — Long-Term Support LTS is a release type used across many technologies (Node.js, Ubuntu, Java, .NET, Angular, etc.) that signals extended maintenance commitment.
What it means: The vendor commits to providing security patches and critical bug fixes for an extended period — typically 2–5 years, compared to 6–12 months for "Current" releases.
Node.js specifically: • Current (odd versions were previously odd-numbered): Newest features, shorter support window (~6 months active) • Active LTS: Receives new features, bug fixes, and security patches • Maintenance LTS: Only critical security fixes • EOL (End of Life): No more updates — time to upgrade
In practice: Production systems should always run an LTS version. "We upgraded to Node 22 LTS when it entered Active LTS status — our team avoids running EOL versions in production."
Saying it aloud: Always spell it out: "el-tee-es" or say the words: "long-term support." Never "luts."
5 / 10
A developer says: "We need to read the changelog before upgrading — v4.0.0 might have breaking changes." What is a "breaking change"?
Breaking change — a critical semver concept "Breaking change" is one of the most important terms in software versioning and release communication.
Definition: A change to a library, API, or tool that removes or alters existing behaviour in a way that requires consumers to update their code. After a breaking change, code that worked before may throw errors, produce wrong results, or fail to compile.
Examples of breaking changes: • Removing a function from an API • Renaming a parameter • Changing a return type (e.g., object → array) • Requiring a new mandatory field • Changing the behavior of an existing method
Non-breaking (backwards-compatible) changes: • Adding a new optional field • Adding a new endpoint that didn't exist before • Fixing a bug that gave wrong results
Semver connection: Breaking changes trigger a MAJOR version bump. That's why jumping from v3.x.x to v4.0.0 is a signal to read the changelog carefully.
Changelog = a file (usually CHANGELOG.md) documenting what changed in each version. "Check the changelog" is standard advice before any major upgrade.
6 / 10
Sarah from the Backend Team just posted this comment on your PR: 'We've bumped v1.2.3 to v1.2.4 – a small fix for a reported bug.' Considering Semantic Versioning, what is Sarah *primarily* communicating?
Sarah's message indicates a 'minor' version bump. Semantic Versioning defines 'minor' as introducing backwards-compatible fixes without new features or breaking changes. Options A and B misinterpret the meaning of minor releases; option C is incorrect because it describes a major upgrade. Option D also incorrectly suggests adding functionality.
7 / 10
You're drafting a PR description for a new feature: 'This update introduces user authentication via JWT.' Your team lead asks you to align the version number with Semantic Versioning principles. Which of the following is the MOST appropriate choice for the major version number in this scenario?
Semantic Versioning dictates that a 'major' version update (represented by a '2' or higher) signifies incompatible API changes. Introducing JWT authentication fundamentally alters the user authorization flow, making it a breaking change. Options A and B are incorrect as they don't represent a major semantic shift; option D is simply not applicable in this scenario.
8 / 10
The API response from the server indicates: `{"version": "5.0.1-beta"}`. What does the '-beta' suffix signify according to Semantic Versioning?
The '-beta' suffix in Semantic Versioning identifies a pre-release version. These versions are not considered stable and may contain bugs or incomplete features. They signal that the API is subject to change before the final release. Options A, C, and D all misinterpret the purpose of the beta suffix.
9 / 10
During a standup meeting, Mark says: 'We're upgrading our dependency on the 'AwesomeLib' from version 2.1.0 to 2.2.0.' What does Mark *primarily* want the team to understand about this change?
Semantic Versioning classifies upgrades as 'major' when they introduce incompatible API changes. Moving to a new minor version (2.2.0 from 2.1.0) *can* include breaking changes, even if the release notes don't explicitly state it. Options A and B are incorrect; option D is too simplistic.
10 / 10
You receive this error message from a deployed service: 'Version mismatch detected: Service version 3.2.1 does not match code version 3.2.0.' What is the *most likely* cause of this issue, in terms of Semantic Versioning?
Semantic Versioning relies on consistent versions across environments. If the service is running an older version (3.2.1) while the code repository contains a newer one (3.2.0), it indicates a divergence in the version numbers that needs to be addressed through either deploying the updated code or downgrading the service's version.
What will I practise in "Version Numbers & Semantic Versioning"?
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.