Maintenance Branch Configuration for semantic-release

Maintenance Branches for Legacy Versions

Maintenance branches allow you to continue releasing patches for older major versions while developing new features on the main branch.

Configuration

{
  "branches": [
    "+([0-9])?(.{+([0-9]),x}).x",
    "main",
    {"name": "next", "prerelease": true}
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/npm",
    "@semantic-release/github"
  ]
}

How Maintenance Branches Work

The glob pattern +([0-9])?(.{+([0-9]),x}).x matches branch names like:

Branch	Versions Released
1.x	1.x.x (patches for v1)
2.x	2.x.x (patches for v2)
1.5.x	1.5.x (patches for v1.5 only)
main	Latest major/minor/patch

Workflow Example

1. You're on v2.x (main branch)
2. A critical bug is found in v1.x
3. Create/checkout the 1.x branch from the last v1 tag
4. Cherry-pick or write the fix
5. Push to 1.x — semantic-release publishes v1.x.y

Version Range Constraints

semantic-release ensures that maintenance branches never publish versions that overlap with the main branch:

• 1.x branch can only publish >=1.0.0 <2.0.0
• main branch publishes >=2.0.0

npm Distribution Tags

Maintenance releases are published under their own dist-tag:

npm install my-package@release-1.x  # Latest v1 patch
npm install my-package              # Latest (v2+)