Unclear how to release a patch of an old version

[silverjam]

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

That said, I am trying to understand how we would configure python-semantic-release to enable us to release a patch version or hotfix of an old version. In our code base we have versions like 0.2.11 and 0.15.12 -- if we currently have 0.2.11 pushed to a production environment and need to release a patch (or hotfix) version (for example 0.2.12 or 0.2.12-hotfix.1 if attempting a "prerelease") when using python-semantic-version it seems to want the next release to be 0.15.13.

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!

[codejedi365]

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.

[codejedi365]

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.

[silverjam]

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

[codejedi365]

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

[silverjam]

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.