Maintenance branch vs prerelease branch in semantic-release for backporting a fix

Choosing the Correct Branch Strategy

For backporting a bug fix to an older major version (e.g., 1.x) while the main line has progressed to 2.x, a maintenance branch is the correct choice. A prerelease branch is intended for upcoming unstable features, not for supporting legacy stable versions.

Trade-offs: Maintenance vs. Prerelease

Feature	Maintenance Branch (e.g., 1.x)	Prerelease Branch (e.g., beta)
Version Result	Stable patch (e.g., 1.2.1)	Prerelease tag (e.g., 1.2.1-beta.1)
Distribution	Published to latest or specific tag	Published to a dist-tag (e.g., @beta)
Consumer Impact	Standard update via semver range	Requires explicit opt-in to the prerelease tag

Diagnosing "No Release Published"

When CI completes without error but no package is published, you must distinguish between a configuration mismatch and a lack of triggering commits. Assuming a recent version of semantic-release, check your logs for these specific patterns:

• Branch Not Matched: The logs will typically omit any mention of "analyzing commits" for the current branch. You will see a message similar to "No release branches found" or the process will exit immediately after the initial environment check without entering the analysis phase.
• No Relevant Commits: The logs will explicitly state that the branch was matched, but then report "No relevant changes found" or "No release to be published" after listing the commits it analyzed.

Verification: Run the release with the DRY_RUN=true environment variable. This will explicitly log which branch is being targeted and which commits are being parsed without performing the actual publish.

The Impact of Squashing Backports

Squashing a backport commit does not change which commits are analyzed, but it does change the analysis result. semantic-release analyzes the commit history between the last Git tag on that branch and the current HEAD.

• If you squash a fix: commit into a generic merge: or chore: commit, the release will not be triggered.
• If the squash commit maintains a Conventional Commit header (e.g., fix: resolve memory leak), it will trigger the patch release normally.

Missing Diagnostic: Please provide the branches array from your .releaserc or package.json configuration. If the syntax uses an outdated format (e.g., from v10 or earlier), the branch may be silently ignored by newer versions of the tool.