Release Engineering & Support Windows

Release Engineering and Artifact Support Windows

A web application deployed continuously has one version in production. Software that customers install — libraries, SDKs, CLIs, mobile apps, on-premises products, container images, firmware — has many versions running at once, some for years. Customers need to know which versions still receive security fixes, how to upgrade safely, and that the artifact they downloaded is genuinely yours. Release engineering is the discipline that answers those questions: how versions are numbered and built, which ones are maintained, how fixes reach them, and how old versions are retired.

Without explicit policies, teams drift into supporting everything forever or nothing at all — and discover the gap when a critical vulnerability arrives and nobody knows which branches to patch.

TL;DR

Choose a versioning scheme (SemVer, CalVer) and state what each part of the version promises.
Maintain release branches for supported versions; publish a support policy with dates.
Define LTS releases if customers need long upgrade cycles, and limit how many versions you maintain.
Fix on the main branch first, then backport to supported branches and cut patch releases.
Record provenance: build from tagged commits in CI, sign artifacts, publish SBOMs and attestations.
Announce deprecations and end of support early, keep upgrade paths tested, and retain artifacts for supported versions and audits.

Quick Example

A published support policy (for example in SUPPORT.md):

Backporting a security fix and cutting a signed patch release:

The release pipeline — not a developer laptop — builds artifacts from the tag, generates provenance and an SBOM, signs everything, and publishes release notes.

Core Concepts

Versioning Schemes

Whatever the scheme, define what counts as a breaking change for your product — public API, configuration format, data migrations, supported platforms — and keep that promise. See API Versioning.

Release Branches and Maintained Versions

Development happens on main. Each release line that will receive fixes gets a release branch (release/2.4). Maintaining a branch means building, testing, and releasing it — so the number of maintained branches is a direct cost. Most projects support the current release plus one or two older lines, often including an LTS line with a longer, published window.

Backports and Patch Releases

Fix on main first (with tests), so the fix is never lost in future releases.
Cherry-pick to each supported release branch where the bug exists; adapt where code has diverged.
Run the full test suite on each branch.
Tag and publish patch releases with release notes and, for security fixes, advisories.

Security fixes may be developed privately and released to all supported branches at once, coordinated with disclosure.

Provenance, Signing, and SBOMs

Customers and auditors increasingly ask: was this artifact built from that source, by your pipeline, without tampering? Build releases only in CI from tagged commits, sign artifacts (for example with Sigstore cosign or platform signing), publish SLSA provenance attestations, and attach a software bill of materials listing dependencies. Reproducible builds strengthen these guarantees further. See Software Supply Chain Security.

Compatibility and Upgrade Paths

State which upgrades are supported — for example, directly from any supported version to the latest — and test them in CI with real data from older versions, especially database and configuration migrations. Pair breaking changes with migration guides and, where possible, automated migration tools.

Deprecation and End of Support

Publish dates in machine-readable form where possible so customers' tooling can flag unsupported versions.

Artifact Retention

Keep released artifacts, signatures, provenance, and SBOMs available for every supported version and for as long as contracts, audits, or regulations require — often years after end of support. Retain the build inputs (source tags, dependency lockfiles, base images) needed to rebuild a patch for an old line. Clean up unreleased and pre-release builds aggressively. See Container Image Registries and Lifecycle.

Release Automation

Release tooling: release-please, semantic-release, Changesets, GoReleaser, and similar tools compute versions, generate changelogs, and publish artifacts from conventional commits or change files.
Release notes: generated drafts, edited by humans for clarity. See Release Notes and Changelogs.
Release trains: fixed-cadence releases make timing predictable for customers and teams.
Freeze and stabilization windows: short, explicit periods before major releases, rather than open-ended code freezes.

Best Practices

Publish the Support Policy

Customers plan upgrades around it. A clear table of versions, statuses, and dates prevents surprises and support escalations.

Support Fewer Versions Well

Every maintained branch multiplies testing and backporting effort. Shorter support windows with smooth upgrades usually serve customers better than many half-maintained branches.

Build Releases Only in CI

Releases from a controlled pipeline, triggered by signed tags, with provenance and signatures, are reproducible and trustworthy.

Test Upgrades, Not Just Releases

Run automated upgrade tests from each supported version to the new release, including data migrations.

Common Mistakes

Fixing Only the Release Branch

Implicit Support Windows

Releases Built on Laptops

FAQ

What is release engineering?

The practice of building, versioning, packaging, signing, and publishing software releases, and maintaining supported versions over time with backports, patch releases, and clear support and deprecation policies.

What is an LTS release?

A long-term support release that receives fixes — usually security and critical bug fixes — for a longer published period than regular releases, for customers who cannot upgrade frequently.

How many versions should we support?

As few as customers can accept, typically the current release plus one or two previous lines or one LTS line. Each additional branch adds testing, backporting, and release effort.

What is a backport?

Applying a fix from the main development branch to an older, still-supported release branch, then releasing it as a patch version.

Why do artifacts need provenance and SBOMs?

Provenance shows which source, build process, and environment produced an artifact; SBOMs list its dependencies. Together with signatures, they let customers verify integrity and respond quickly when a dependency vulnerability is disclosed.