Maintenance branch not published

[fourass]

Current behavior

We have released version 4.118.0, 4.118.1 4.118.2 4.118.3 .. and went to 4.124.1 and then we discovered that we have a bug in production, so we want to do a hotfix, using the 4.118.0 (the version deployed in production currently ) When I run the maintenance branch, it fails with this message

Based on the releases published on other branches, only versions within the range >=4.118.0 <4.118.1 can be published from branch 4.x.
The following commit is responsible for the invalid release:
    * fix: SRE-1121 test range (3ae5595)
This commit should be moved to a valid branch with git merge (https://git-scm.com/docs/git-merge) or git cherry-pick (https://git-scm.com/docs/git-cherry-pick) and removed from branch 4.x with git revert (https://git-scm.com/docs/git-revert) or git reset (https://git-scm.com/docs/git-reset).
A valid branch could be master.

I tried with both 4.x and 4.118.x, and expected this to work, but it didn't.. is it because we already have the 4.118.1 ? which is not a maintenance branch, but just a fix we pushed.

Expected behavior

From my understanding even if the tag 4.118.1 and 4.118.2, 4.118.3 exists, semantic release should create version 4.118.4

semantic-release version

21.1.2

CI environment

GItHub and GitHub action and I'm using cycjimmy/semantic-release-action@v4.0.0 action

Plugins used

@semantic-release/changelog@6.0.0 @semantic-release/github@9.0.0 @semantic-release/git@10.0.0 @semantic-release/exec@6.0.0 @semantic-release/commit-analyzer@11.0.0 @semantic-release/npm@11.0.0 @semantic-release/release-notes-generator@12.0.0

semantic-release configuration

I have my configuration is a .releaserc file

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/changelog", {
      "changelogFile": "CHANGELOG.md"
    }],
    ["@semantic-release/npm", {
      "npmPublish": false
    }],
    ["@semantic-release/exec", {
      "prepareCmd": "echo triggered from release branch",
      "successCmd": "echo version : ${nextRelease.version} and ${nextRelease.type}"
    }],
    ["@semantic-release/git", {
      "assets": ["package.json", "CHANGELOG.md"],
      "message": "chore(release): ${nextRelease.version}\n\n${nextRelease.notes}\n\n[skip ci]"
    }],
    ["@semantic-release/github", {
    }]
  ],
  "branches": [
    '4.118.x',
    'master'
  ],
  "debug": true,
  "dryRun": false
} 

CI logs

This is the error logs

[travi]

you've left out an important detail to enable us to help you. at which point in the commit history did you create the maintenance branch?

you should create it at the tag for the latest existing version in the 4.118 line (4.188.3 from what you've described). if you create it earlier than that, like at 4.118.0, semantic-release would attempt to release 4.118.1 because it does not exist in the history of your maintenance branch. doing so would fail because 4.118.1 already exists in the registry

[fourass]

you've left out an important detail to enable us to help you. at which point in the commit history did you create the maintenance branch?

you should create it at the tag for the latest existing version in the 4.118 line (4.188.3 from what you've described). if you create it earlier than that, like at 4.118.0, semantic-release would attempt to release 4.118.1 because it does not exist in the history of your maintenance branch. doing so would fail because 4.118.1 already exists in the registry

Thank you for your reply

Indeed, I created it at the line 4.118.0, to better contextualise this, the version 4.118.1..4.118.3 were already created, the other version up to 4.124.1 were created.

I doubted it was the issue, but if I don't want to have the changes from 4.118.2 and 4.118.3, since production is on 4.118.1, how can I proceed ?

[travi]

.2 and .3 have already been published and a registry won't allow republishing existing versions. You need to publish .4 regardless, just because of that. If you don't want the changes from .2 or .3, you need commit(s) to revert those changes

[fourass]

Thanks again for the reply I guessed it would be related to that But I expected semantic release to detect the .2 and .3 and automatically create a .4 for me which seems more convenient.. What you're suggesting is to checkout to .3 and revert the 3 commits created by .1 .2 and .3