Release Tags & Versioning Vocabulary Exercises

1 / 5

A release manager announces: "The release is tagged as v3.2.1."

What do the three numbers in semantic versioning represent?

SemVer (Semantic Versioning) — MAJOR.MINOR.PATCH:

Segment	When to bump	Backward compatible?
MAJOR	Breaking API change	No — requires consumer updates
MINOR	New feature added	Yes
PATCH	Bug fix	Yes

Pre-release labels: v1.0.0-alpha.1, v1.0.0-rc.2. Convention: 0.x.x = unstable/experimental API. Key vocabulary: breaking change signal (major bump), backward compatibility, pre-release label.

2 / 5

A DevOps engineer says: "We use annotated tags for production releases."

What distinguishes an annotated tag from a lightweight tag?

Annotated vs. lightweight tags:

Type	Storage	Contains
Annotated	Full Git object	Tagger identity, date, message, optional GPG signature
Lightweight	Just a reference	Pointer to a commit SHA — no metadata

Create annotated: git tag -a v1.0.0 -m "Release notes". GPG-signed: git tag -s v1.0.0. Key vocabulary: annotated vs. lightweight tag, tag object, tag message, signing releases.

3 / 5

A CI/CD pipeline is configured to trigger only on tags matching v[0-9]*.

Why do teams typically limit release pipelines to specific tag patterns?

Tag pattern filters for release pipelines:

Tag	Should trigger production deploy?
`v3.2.1`	Yes — versioned release tag
`test-tag`	No — QA marker, should not deploy
`wip-v2`	No — work-in-progress bookmark

Pattern: refs/tags/v* or v[0-9]+.[0-9]+.[0-9]+. Key vocabulary: release trigger pattern, CI tag filter, deployment gate, tag naming discipline.

4 / 5

An engineering blog post says: "The team follows calendar versioning (CalVer) instead of SemVer."

When is CalVer an appropriate versioning choice?

CalVer vs. SemVer — choosing the right versioning scheme:

Scheme	Format example	Best for
CalVer	`22.04`, `2025.03.15`	OS releases, data exports, time-sensitive tooling
SemVer	`3.2.1`	Libraries with explicit API contracts

Key vocabulary: CalVer, version semantics, date-based versioning, API stability vs. release timeline.

5 / 5

A roadmap note reads: "The deprecated v1.x branch still receives security patches on a long-term support basis."

What does maintaining an LTS branch require from the team?

LTS (Long-Term Support) branch maintenance:

LTS practice	Rationale
Cherry-pick security fixes only	Minimise change risk on stable branch
Do NOT merge all main changes	Would break backward compatibility
Publish EOL date	Users can plan migration to supported version

Key vocabulary: LTS branch maintenance, cherry-pick backport, security patch release, EOL (End of Life) communication, support window.