LTS = Long-Term Support (extended maintenance window)
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.