5 exercises on shipping the native way: cutting and drafting a release, tagging it, annotated vs lightweight tags, bumping the version, and semantic versioning.
Key patterns
cut / ship a release; draft a release then publish
tag a release; push tags (--tags)
annotated (metadata) vs lightweight tag
bump the version → a "version bump"
semantic versioning: MAJOR.MINOR.PATCH
0 / 5 completed
1 / 5
The team has finished testing v2.0 and is ready to ship it. The idiomatic phrase release engineers use is to:
Cut a release — create and publish a new version:
To cut a release means to finalise a version: tag the commit, build artifacts, and publish release notes. Just as you "cut a branch", you "cut a release" — "cut" is the standard release-engineering verb.
Release collocations:
cut a release → produce a new versioned release
ship / roll out a release → deliver it to users
tag a release → mark the exact commit with a version tag
draft a release → prepare release notes before publishing
hotfix release → an urgent patch release
Why not the rest? "Fire", "throw" and "strike" a release are not English collocations. The fixed verb is cut (a release).
2 / 5
Your project follows semantic versioning (MAJOR.MINOR.PATCH). You added a new backward-compatible feature, so you increase the MINOR number. The verb for raising a version number is to:
Bump the version — increment the version number:
To bump the version is to increase it — e.g. 1.4.0 → 1.5.0 for a new feature. Tools like npm version minor do this automatically.
Semantic versioning (SemVer) rules:
MAJOR → breaking changes (2.0.0)
MINOR → new, backward-compatible features (1.5.0)
PATCH → backward-compatible bug fixes (1.4.3)
Version collocations:
bump the version → increment it (a "version bump")
pin a version → lock a dependency to an exact version
tag the version → create a Git tag like v1.5.0
Why not the rest? "Raise", "lift" and "push" don’t collocate with version. The standard developer verb is bump.
3 / 5
You want a permanent, named marker on a specific commit that also stores a message, the tagger’s name, a date, and can be GPG-signed. You should create an:
Annotated tag — a full tag object with metadata:
An annotated tag (git tag -a v1.0 -m "Release 1.0") is stored as a full Git object: it records a message, tagger, date, and can be signed. Annotated tags are recommended for releases.
Annotated vs lightweight tags:
annotated tag → full object with message + metadata; use for releases
lightweight tag → just a name pointing at a commit (like a private bookmark); no metadata
tag a release → mark the release commit (e.g. v2.1.0)
Why not the rest? A lightweight tag has no metadata; "shallow tag" and "floating tag" aren’t Git concepts. For rich release metadata you use an annotated tag.
4 / 5
On GitHub you prepare the release notes and assets but don’t publish yet — you save it as a hidden, unpublished version you can finish later. This is to:
Draft a release — prepare it without publishing:
A draft release on GitHub is saved but not public: you can write release notes, attach binaries, and choose the tag, then publish when ready. "Draft" is the precise term GitHub uses (a "Save draft" button).
GitHub release collocations:
draft a release → prepare it privately
publish a release → make it public
attach assets / binaries → add downloadable files
pre-release → mark it as a beta/RC, not "latest"
generate release notes → auto-build a changelog from merged PRs
Why not the rest? "Stage" relates to Git’s index, "stash" shelves working changes, and "queue" isn’t used for releases. The correct verb is draft.
5 / 5
A version string like 1.4.2 follows a widely-adopted convention with three numbers (MAJOR.MINOR.PATCH) and clear rules about when each increments. This convention is called:
Semantic versioning (SemVer) — meaning-based version numbers:
Semantic versioning (semver.org) defines MAJOR.MINOR.PATCH so a version number communicates the type of change: breaking, feature, or fix. It lets dependency managers reason about compatibility (e.g. ^1.4.2 allows compatible updates).
SemVer terminology:
semantic versioning / SemVer → the MAJOR.MINOR.PATCH scheme
breaking change → forces a MAJOR bump
pre-release tag → 1.0.0-rc.1, 2.0.0-beta
version range / caret & tilde → ^ and ~ constraints
Why not the rest? "Chronological" (e.g. CalVer, 2024.06) uses dates; "incremental"/"sequential" aren’t named schemes. The convention with rule-based MAJOR.MINOR.PATCH is semantic versioning.