Skip to content
Latchkey

What Is a Release?

A release is a specific, versioned version of your software that is made available to users, often accompanied by notes describing what changed.

A release is the user-facing milestone of software delivery. Where a build is a technical output and a deployment is an infrastructure action, a release is the moment the world gets new functionality, packaged, named, and documented.

What a release is

A release bundles a set of changes into a named, versioned unit and makes it available to users. It usually carries a version number, a tag in source control, the artifacts being shipped, and a changelog describing the changes. A release is something you can point to and say "this is what users are running."

How releases are versioned

Most teams use semantic versioning, where a version like 2.4.1 encodes the kind of change: a bump in the first number signals a breaking change, the second adds features, the third fixes bugs. Version numbers let users and dependent systems reason about compatibility at a glance.

Release versus deployment

Deploying is putting code on infrastructure; releasing is making it available to users. You might deploy a build to production with a new feature hidden behind a flag, then "release" it days later by enabling the flag, no new deployment required. Keeping the concepts separate gives you control over risk and timing.

An example

A team tags commit history as v3.0.0, builds the release artifacts, publishes a changelog noting a new dashboard and a breaking API change, and announces it. Users upgrade knowing exactly what changed and that the major version bump signals a breaking change.

Why releases matter

Releases give changes a name, a version, and a record. That makes support easier ("which release are you on?"), rollbacks clearer (revert to the previous release), and communication honest (the changelog). Automating release creation removes manual toil and human error from cutting a version.

Key takeaways

  • A release is a named, versioned set of changes made available to users.
  • Semantic versioning communicates the nature of each release.
  • Releasing is distinct from deploying and can be controlled separately.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →