How to start 1.0.0 with pre-release instead of stable?

[faustbrian]

#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 at 0.1.0 but since we're forced to start with 1.0.0 here - what's the expected approach to releasing non-production-ready pre-releases before tagging a 1.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 a 1.0.0 on the latest 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 once 1.0.0 has been tagged on the latest channel. What's the recommended approach here? We would want something like 1.0.0-next.1 on the next channel before tagging 1.0.0 on the latest 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?

[SvenStaehs]

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? 🤔

[SvenStaehs]

to answer my own question: It does seem to work. I created a branch named beta from my main branch, then pushed semantic-release configuration onto beta and got a workflow creating a pre-release for 1.0.0: v1.0.0-beta.1

I expect that semantic-release will make the proper 1.0.0 release when the config moves to main, but I'm not ready for that, so can't comment 😉

[HokkanenTeemu]

I'm at the same point also and creating pre-release of 1.0.0 is acceptable solution for me but I cannot get it to work. @SvenStaehs Could you share the configuration you used?
I get following error even though I have tried to use default config and custom config for release branches:

This test run was triggered on the branch beta, while semantic-release is configured to only publish from main, therefore a new version won’t be published.

[SvenStaehs]

@HokkanenTeemu I don't think I did anything special, only had to specify the default branches definition because our default branch name is "main", not "master"... This is from our package.json:

  "release": {
    "branches": [
      "+([0-9])?(.{+([0-9]),x}).x",
      "main",
      "next",
      "next-major",
      {
        "name": "alpha",
        "prerelease": true
      },
      {
        "name": "beta",
        "prerelease": true
      }
    ]
  },

I even found the default, config, it does include prerelease branches: https://github.com/semantic-release/semantic-release/blob/master/lib/get-config.js#L69
So unless you overrode that and removed beta branch, I don't know what's up with that.

[HokkanenTeemu]

@SvenStaehs Thanks, I read your earlier message again and noticed that you mentioned pushing the configuration to beta -> my issue was that I had only local beta branch as I didn't know it would need to be on remote even when running in dry mode.

[SvenStaehs]

Ah OK, yeah I don't think I made any dry-runs 😅 I simply set a custom registry to publish to that didn't exist so it couldn't do any harm.