Release Management

June 3, 2026 · View on GitHub

English | 中文

Release management must ensure that versions are trackable, changes are explainable, and issues can be rolled back.

Git itself records version history, while GitHub Release, tags, changelogs, and CI/CD turn this history into deliverable version assets.

  • tag
  • release note
  • changelog
  • rollback plan
  • migration note
  • verification note

Release Process

merge -> tag -> release notes -> deploy -> verify -> announce

Tag Conventions

Semantic versioning is recommended:

v2.0.0
v2.0.1
v2.1.0

Common meanings:

  • major: Incompatible changes
  • minor: Backwards-compatible new features
  • patch: Backwards-compatible fixes

What Should Be in a Release Note

Include at least:

  • Key changes
  • Bug fixes
  • Breaking changes
  • Upgrade instructions
  • Rollback procedures
  • Contributors

See Release Note Template for a template.

Hotfix Releases

Hotfixes only address emergency issues in the production environment.

Principles:

  • Small diff
  • Do not mix in refactoring
  • Clear verification
  • Rollback plan in place
  • Backport to the trunk after release

For the process, see Hotfix Process.

Release Pipeline

Public practices like Netflix Spinnaker remind us that for many teams, the real risk is concentrated in the release process, of which the branching model is only a part.

Once a team has PRs, CI, and branch protection, the next things to add are:

  • Linking releases to commits or tags
  • Release records include release notes
  • Clear checkpoints before production release
  • Manual approval points for high-risk releases
  • Trackable verification results post-release
  • Clear rollback paths

See Netflix Spinnaker and Release Pipeline Practices for details.

Release Flow and Daily Deployment

The Microsoft Release Flow experience is suited for teams with fixed sprints and fixed release windows:

  • Daily development enters the trunk
  • Cut a release branch from the trunk before release
  • The release branch only accepts stability fixes
  • Sync back to the trunk after fixes are completed
  • Trace release versions using tags and release notes

Slack's publicly shared deployment practices place more emphasis on "continuous small-batch releases": breaking down risks into daily deployments through automated checks, deployment queues, observability, and rollback paths.

These two types of practices differ in direction, but their common ground is clear: release management cannot solely rely on branch naming; it must string together verifications, approval points, release records, monitoring, and rollback paths.

If the team has fixed release windows, Microsoft Release Flow can be prioritized as a reference. If the team deploys frequently, Slack Deploys and Netflix Spinnaker can be prioritized. For more case comparisons, see Big Tech Engineering Practice Decision Map.

Further Reading