Release Types

Release Types#

Versioning, pre-release tiers, distribution channels, and stability tiers the operator meets when shipping software or pulling someone else’s. Cross-vendor vocabulary; not every project uses every term, but the operator who recognises the set reads release notes faster.

For the SDLC framing around releases, see Teamwork. For the version-control mechanics, see VCS.

Versioning schemes#

Scheme

Example

Notes

SemVer

2.7.13

MAJOR.MINOR.PATCH. Breaking, additive, fix. The default for libraries with public APIs.

CalVer

2026.05.16, 24.04

Year-anchored. Ubuntu, JetBrains, pip, the calver community. Good when release cadence is the truth, not compatibility rules.

RomVer

3.1.4

“Romantic” versioning. Major bumps mean “big enough to brag about” rather than “breaking”. Mostly anti-pattern in 2026; called out so the operator recognises it.

0ver

0.42.0, 0.0.1

Pre-1.0 SemVer where MINOR may break. Common in early projects; ZeroVer.com mocks the convention while acknowledging it.

Date-suffixed

1.2.0-20260516

Adds a date to a base version. Useful for snapshots from a stable line.

Hash-suffixed

1.2.0-g8a1f3c

git describe style. Identifies the exact commit after the last tag. Internal builds.

SemVer component bumps#

Bump

Trigger

Operator angle

Major

Backward-incompatible change

Read the migration guide before pulling. Pin the old major until the operator can absorb the break.

Minor

Backward-compatible feature

Safe to take with the constraint operator pinned (^1.2 / ~1.2).

Patch

Backward-compatible fix

Take it. Pin no tighter than =1.2.3 only when the fix is suspected.

Build metadata

+sha256.abc, +linux-amd64

Not version-precedence-significant; identifies the artefact, not the release.

Pre-release identifiers#

In SemVer, identifiers come between the MAJOR.MINOR.PATCH core and any build metadata, joined by -.

Identifier

Example

Meaning

dev / nightly

2.0.0-dev.20260516

Tip-of-trunk builds. No stability promise. May contain half-merged features.

alpha

2.0.0-alpha.3

Feature-incomplete preview. APIs and behaviours change.

beta

2.0.0-beta.1

Feature-complete preview, bugs expected. APIs typically frozen.

rc (release candidate)

2.0.0-rc.2

Candidate for promotion to stable. No new features. Only blocker fixes between rc and final.

pre / preview

2.0.0-preview.1

Vendor-specific (Microsoft, JetBrains). Roughly beta.

edge / canary

2.0.0-canary.4321

Continuous-delivery preview. Faster cadence than nightly; often per-commit.

Per SemVer 2.0, pre-release versions have lower precedence than the corresponding stable: 2.0.0-rc.1 < 2.0.0.

Release channels#

The labels under which the project ships its builds.

Channel

Typical cadence

Notes

Nightly

Daily

Latest tip-of-trunk. Breaks routinely. Used by contributors and bleeding-edge adopters.

Dev / Canary

Continuous

Per-commit or per-PR build. Even rougher than nightly.

Edge

Continuous to weekly

Rolling preview between dev and beta. Chrome uses this label.

Beta

Weeks

Feature-frozen preview. Public test channel.

Stable

Months

The default channel. What apt install gives a fresh user.

LTS (long-term support)

Years

Security fixes only, for a known support window. Ubuntu LTS, Node.js Active LTS, Java LTS.

ESM (extended security maintenance)

Years past LTS

Paid or restricted post-LTS support. Ubuntu Pro, RHEL ELS.

Rolling

Continuous

No discrete versions, only “latest”. Arch, Tumbleweed, Gentoo. Pull when ready, not on a schedule.

Stability tiers#

The label a project puts on a feature, API, or product within a release.

Tier

Synonyms

Meaning

Experimental

tech preview, lab, incubating

Anything can change without notice. No SLA.

Alpha

early access

Structure is forming; partial functionality.

Beta

public preview

Feature complete; bugs and API tweaks expected.

GA (general availability)

stable, generally available, production-ready

Backed by the vendor’s stability and support promises.

Mature

long-term, hardened

GA plus years of production use; rare in vendor vocabulary, common in operator vocabulary.

Deprecated

obsolete, legacy

Still works; scheduled for removal. Operator stops starting new work on it.

End-of-life (EOL)

retired, sunset, discontinued

No further support, security fixes, or downloads. Migrate off.

Channel labels by vendor#

Same idea, different names. The operator who recognises the mapping reads cross-vendor release notes faster.

Vendor

Bleeding

Preview

Stable

Long-term

Ubuntu

daily ISO

dev (current dev release)

stable (interim release)

LTS / ESM

Debian

sid (unstable)

testing

stable

oldstable, oldoldstable

Fedora

rawhide

branched

stable (current N, N-1)

n/a

Chrome / Edge

canary

dev / beta

stable

extended stable

Firefox

nightly

dev / beta

release

ESR

Node.js

nightly

current

active LTS

maintenance LTS

Python

main (CPython)

alpha / beta / rc

stable

bugfix vs security per branch

Rust

nightly

beta

stable

n/a (6-week cadence)

Kubernetes

n/a

alpha / beta API

GA API

LTS (since 1.32)

Microsoft .NET

daily

preview / RC

GA

LTS / STS

Release-cadence patterns#

Pattern

Example

Notes

Time-based

Ubuntu (6 mo), Rust (6 wk), Chrome (4 wk)

Ship on the clock; features missing the train wait for the next.

Feature-based

traditional waterfall, some niche projects

Ship when the feature set is done. Slips when scope grows.

Continuous

SaaS, rolling distros, main branch deploys

Every accepted change goes out. Feature flags hide in-flight work.

Train-based

Linux kernel (mainline + LTS)

Periodic merge windows + stabilisation periods. LTS branches forked from selected releases.

References#

Contents