Release Branch Naming with Version Numbers

Release Branch Naming

Release branches are created when the team is ready to prepare a new version for deployment. They allow final bug fixes, documentation updates, and version bumps while the develop branch continues to accept new features for the next cycle.

Standard Formats

release/v{major}.{minor}.{patch}
release/{version-name}
release/{date}-{description}

Examples

Release Type	Branch Name
Semantic version	release/v2.3.0
Named release	release/aurora
Date-based	release/2026-03-sprint-12
Feature release	release/v3.0.0-beta-new-dashboard

Semantic Versioning in Branch Names

Most teams follow SemVer (Semantic Versioning) for release branches:

• Major (v2.0.0) — Breaking changes, API incompatibilities
• Minor (v2.3.0) — New features, backward-compatible
• Patch (v2.3.1) — Bug fixes only, backward-compatible

The branch name should reflect the target version, not the current one. When you create release/v2.3.0, you are signaling that this branch will become version 2.3.0 when merged and tagged.

Release Branch Lifecycle

1. Branch from develop when feature-complete for the release
2. Only bug fixes, documentation, and version bumps are allowed
3. When stable, merge to main and tag with the version number
4. Back-merge to develop to incorporate any fixes made during stabilization

Tips for Release Branch Names

• Always include the version number for traceability
• Use the v prefix consistently (v2.3.0, not 2.3.0)
• For pre-release versions, append qualifiers: release/v3.0.0-rc.1
• Avoid adding feature descriptions to release branches — they represent a collection of changes, not a single feature