This is definitely supposed to be a supported ability via release branches but I do believe there likely is a bug with tag resolution that I haven't been able to solve yet.

I wasn't able to find a forum for general questions, so if there's a better place to ask general support questions

This is the correct location for general support questions as of now.

In this scenario we've created a branch from an old version of our main branch where the last tagged version is 0.2.11 -- so the "next" release we'd expect is 0.2.12 or 0.2.12-hotfix.1.

Is there a pattern or path where we could implement our expected behavior? Thanks!

I have simulated your scenario as much as I understood and PSR will provide 0.2.12 if the configuration has prerelease = False. If prerelease is set to true, it does jump to 0.15.12 as the base version to increment from. I think latter section is a bug but I will have to apply further testing.

The configuration concept I used is documented under the Mulitbranch releases section of the documentation. In your case, you are creating a second non-prerelease channel for the special release branch that will diverge from the original history.

# pyproject.toml

[tool.semantic_release.branches.main]
match = '(master|main)'
prerelease = false

[tool.semantic_release.branches."0.2.x"]
match = "0.2.x"
prerelease = false

This image below was the truncated git history that I generated to test your scenario.

When I execute the following command with the 0.2.x branch checked out, I get 0.2.12 as the next version to release.

semantic-release version --print
# 0.2.12

If this does not work in your scenario, please provide some detail on your merging/branching strategy or a log of your git history in graph format (git log --graph --decorate --oneline --all --topo-order) to help me create a more accurate representation.

I wasn't able to find a forum for general questions, so if there's a better place to ask general support questions

This is the correct location for general support questions as of now.

In this scenario we've created a branch from an old version of our main branch where the last tagged version is 0.2.11 -- so the "next" release we'd expect is 0.2.12 or 0.2.12-hotfix.1.
Is there a pattern or path where we could implement our expected behavior? Thanks!

I have simulated your scenario as much as I understood and PSR will provide 0.2.12 if the configuration has prerelease = False. If prerelease is set to true, it does jump to 0.15.12 as the base version to increment from. I think latter section is a bug but I will have to apply further testing.

Ok, I didn't try without prerelease so this is likely the issue.

The configuration concept I used is documented under the Mulitbranch releases section of

Thanks, this looks similar to https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases

Thanks, this looks similar to https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases

This is not the correct documentation. The link above is for the JavaScript variant of semantic-release which is similar but not this project's docs.

Correct Link: Multibranch Releases

Thanks, this looks similar to https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases

This is not the correct documentation. The link above is for the JavaScript variant of semantic-release which is similar but not this project's docs.

Correct Link: Multibranch Releases

Yes I realize that, apologies, I was referencing that doc as an example of what I was trying to accomplish-- the multibranch release doc is similar, but the nodejs version matched our exact use case more closely.

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

I haven't been able to finish the testing of this change to ensure it doesn't impact normal pre-release activity. Hopefully will get back around to this in the next few months as I am merging in some better testing of versioning.

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

I'm sorry, my last two months have been very busy. Not much has moved. This is still a priority and I hope to have it completed in the next few months.

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in backlog

🎉 This issue has been resolved in version 9.15.2 🎉

The release is available on:

• PyPi package
• GitHub release