Semantic Release Configuration for Maintenance Channel

[picosam]

I'm using semantic-release for my versioning needs. I have a master branch with a tag of v1.2.1 on it as the latest, following by multiple v2... tags thereafter.

I need to create branches from the v1.2.1 tag from time to time and call them hotfix/* where I can run semantic-release onto that branch to publish hot-fixes as v1.2.2, v1.2.3, etc. until I don't need to maintain version 1 anymore. I tried the following configuration:

"branches": [
  "master",
  {
    "name": "hotfix/*",
    "range": "1.x",
    "channel": "1.x"
  }
]

in my package.json releases section, but I get the following result when running semantic-release:

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

Is there any way I can achieve my goal with a different config?

[travi]

I need to create branches from the v1.2.1 tag from time to time

i think there is a bit of a misconception of how semantic-release works with your desired approach. a key detail to be aware of is that the version is always bumped based on the previous version that is already in the history of the commits that make up the new release. when you describe multiple branches for independent versions, i dont see a workflow where the produced versions are available for the versions that follow.

instead, we recommend a single branch from the point of the latest version in that release line before the next major was released. that way, the following versions continue to follow the typical git history approach. you can find this process describe in our docs about maintenance releases.

would this approach satisfy your needs?

[picosam]

Thank you for your response!

a key detail to be aware of is that the version is always bumped based on the previous version that is already in the history of the commits that make up the new release. when you describe multiple branches for independent versions, i dont see a workflow where the produced versions are available for the versions that follow.

Yes, and the branch I'm talking about will indeed be taken from master and so will have all this history. Am I not understanding something there?

instead, we recommend a single branch from the point of the latest version in that release line before the next major was released. that way, the following versions continue to follow the typical git history approach. you can find this process describe in our docs about maintenance releases.

would this approach satisfy your needs?

But then what happens if I need to "deploy" my hot-fix directly from its branch and never merge that branch onto master, but destroy it thereafter instead?

[travi]

the branch I'm talking about will indeed be taken from master and so will have all this history. Am I not understanding something there?

never merge that branch onto master, but destroy it thereafter instead

that is sufficient for the first maintenance release, but not the ones that would follow the first. if you dont keep that branch around, no later branches would be aware of your existing hotfix release. since master has already moved on, merging your branch back into master would only produce another release after your v2 release. therefore, there is no way to branch again from master for a follow up hotfix that is still for you v1 release. this is why maintenance release channels must be a long running branch that diverges from master.

does that help to clarify?

[picosam]

Thank you, yes that makes sense. I don't mind creating a branch named "1.0" from master and keeping it around forever for hot fixes then. Would that do it? If so, what would be the correct config for it please?

[travi]

take a look though the details in the maintenance releases docs. it should cover the information you need to accomplish your goal. if you find that there are gaps, we would love any help you could provide for improving the docs.

[rite2hhh]

@travi , I'm piggybacking on this conversation as I see concerns are similar.

I'm seeing this error

  code: 'EINVALIDNEXTVERSION',
  details: 'Based on the releases published on other branches, only versions within the range `>=1.0.0 <1.0.0-alpha.1` can be published from branch `0.x`.\n'

And it complains that the commits made on this 0.x branches need to be moved to main. These commits exist on the main branch

5990da4 <commit message>
414fd68 <commit message>
8fb879f <commit message>
676bcc5 <commit message>

0.x branch (forked from v0.13.1 tag):

$ git log --oneline
8154710 (HEAD -> 0.x, upstream/0.x) <commit message>
df4b9cd Build: Update package.json to publish 0.x release
...
5990da4 <commit message>
414fd68 <commit message>
8fb879f <commit message>
676bcc5 <commit message>
dfa08ce (tag: 0.13.1) Release 0.13.1
6dd84f2 (tag: 0.13.0) Release 0.13.0
3e5d77d (tag: 0.13.0-dev.1) <commit message>
5b18a1a (tag: 0.12.1) Release 0.12.1

main branch:

$ git log --oneline
1a2bdd9 (HEAD -> main, tag: 1.1.1, upstream/main) Release 1.1.1
...
e87b843 (tag: 1.0.0) Release 1.0.0 (#198)
...
5990da4 <commit message>
414fd68 <commit message>
8fb879f <commit message>
676bcc5 <commit message>
6dd84f2 (tag: 0.13.0) Release 0.13.0 (#192)

My branches config in package.json looks like this

      ...
      "branches": [
      "main",
      {
        "name": "0.x",
        "range": "0.x"
      },
     ...

I'm not sure what's wrong here. The config seems to be accurate based on my understanding about "maintenance branches" can you assist?

[rite2hhh]

@travi

The suggested range doesn't make sense either

>=1.0.0 <1.0.0-alpha.1

Isn't 1.0.0 greater than 1.0.0-alpha.1? That range seems invalid