chore(releaserc.js): use proper branches config for semantic release #702
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Btw, we'll need to backmerge this to the release/47.x branch, I guess 👍 |
timowolf
force-pushed
the
chore/semantic-release-branches-config
branch
from
3da0b76 to
7c23b58
Compare
Collaborator
|
🎉 This PR is included in version 48.0.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses 4 points:
latesttag on npmjs.comrangeproperty set to ensure no accidential releaes of a major version happens form a maintenance branch.next-Xversions, which is OK, but RC is more specific and so we should use RC also here.dashboards-demo, so removing that here.AI summary for the first 3 fixes about the branches config:
The issue you're describing—where a release from the
mainbranch unexpectedly gets treated as a prerelease—is most likely caused by the order of branches in your configuration array. Semantic-release processes the branches in the specified order, and this order is critical because versions released from each subsequent branch must be higher than those from the previous one to avoid conflicts (e.g., duplicate versions across branches). Prerelease branches likenextare intended for future or experimental versions and should come after stable branches likemain(and after maintenance branches). Placingnextbeforemaindisrupts this versioning logic, which can result in miscalculated release types, including inadvertently applying prerelease identifiers to stable releases or triggering internal errors that manifest as prerelease behavior.Additionally, your maintenance branch config omits the
rangeproperty, which is optional but recommended to enforce version boundaries (e.g., only allowing patches/minors within1.xonrelease/1.x). Without it, there's no restriction, which could contribute to versioning inconsistencies if combined with the order issue.Here's the fixed configuration, with the branches reordered correctly (maintenance → stable → prerelease),
rangeadded back for maintenance branches,prereleaseset to a string identifier ("rc") instead oftrue(to avoid defaulting to the branch name "next" as the identifier, which is less conventional for RCs), andchannelpreserved or added where appropriate for npm dist-tags:This addresses most points in #673