How to start 1.0.0 with pre-release instead of stable? #2499
Unanswered
faustbrian
asked this question in
Q&A
Replies: 1 comment 5 replies
-
I'm at the same point right now, did you ever try just pushing semantic-release configuration to "next" branch without making that initial release? Maybe that would work, even though it's not described in the cookbook? 🤔 |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
#837 and #1507 recommend to start with
1.0.0
because that's this package chose to go with even though https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase recommends to start at0.1.0
but since we're forced to start with1.0.0
here - what's the expected approach to releasing non-production-ready pre-releases before tagging a1.0.0
?From reading the various recipes like https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/release-workflow/pre-releases.md it seems like you're forced to make a
feat: initial commit
commit to tag a1.0.0
on thelatest
channel before you can start making other releases but that doesn't make any sense in our case because end-users will think it's ready for use once1.0.0
has been tagged on thelatest
channel. What's the recommended approach here? We would want something like1.0.0-next.1
on thenext
channel before tagging1.0.0
on thelatest
channel, which is a few months down the road.I assume the best approach is to manually manage
0.x.x
releases and not use this package until the actual 1.0.0 gets tagged because it doesn't fully comply with the SemVer recommendations?Beta Was this translation helpful? Give feedback.
All reactions