Release version incorrectly incremented

[JeromeCheviet]

The problem

Hello,

Like requested in the issue #838 I open a new bug.

Like I said, we practice the trunk base development and we release from trunk.

We use Python Semantic Release with Gitlab and we have a specific configuration file with a little more commit type.

We have a first job to make pre-release versions and a second to make final release versions.

Until PSR 9.5.0 we have no problem, but since 9.6.0 the incrementation of pre-release version is not incremented on the last release version:

I have a pre-release version 0.2.0-beta.3 and I make an 0.2.0 release version on the same branch.
I release a patch and PSR make me a 0.2.0-beta.4. And when I make the release I have a 0.2.1 release version.

In resume: 0.2.0-beta.3 -> 0.2.0 -> 0.2.0-beta.4 -> 0.2.1

Expected behavior

I have a pre-release version 0.2.0-beta.3 and I make an 0.2.0 release version on the same branch.

I release a new pre-release patch 0.2.1-beta.1 and after a couple of beta version I make a release 0.2.1.

I would like: 0.2.0-beta.3 -> 0.2.0 -> 0.2.1-beta.1 -> 0.2.1

Environment

We use a docker image based on python:3.12-alpine and versions are:

/ # python --version
Python 3.12.3
/ # pip --version
pip 24.0 from /usr/local/lib/python3.12/site-packages/pip (python 3.12)
/ # semantic-release --version
semantic-release, version 9.7.1
/ # pip freeze
annotated-types==0.6.0
certifi==2024.2.2
charset-normalizer==3.3.2
click==8.1.7
click-option-group==0.5.6
dotty-dict==1.3.1
gitdb==4.0.11
GitPython==3.1.43
idna==3.7
importlib_resources==6.4.0
Jinja2==3.1.4
markdown-it-py==3.0.0
MarkupSafe==2.1.5
mdurl==0.1.2
pydantic==2.7.1
pydantic_core==2.18.2
Pygments==2.18.0
python-gitlab==4.4.0
python-semantic-release==9.7.1
requests==2.31.0
requests-toolbelt==1.0.0
rich==13.7.1
setuptools==69.2.0
shellingham==1.5.4
smmap==5.0.1
tomlkit==0.12.4
typing_extensions==4.11.0
urllib3==2.2.1
wheel==0.43.0
/ # 

We use poetry for our projects.

Configuration

PSR configuration:

[tool.semantic_release]
version_toml = ["pyproject.toml:tool.poetry.version"]
commit_message = "chore(release): {version}"
tag_format = "{version}"

[tool.semantic_release.branches.main]
match = "(main|master)"
prerelease = false
prerelease_token = "beta"

[tool.semantic_release.commit_parser_options]
allowed_tags = ["build", "chore", "ci", "docs", "feat", "fix", "perf", "style", "refactor", "revert"]
minor_tags = ["feat"]
patch_tags = ["build", "chore", "ci", "fix", "perf", "style", "refactor", "revert"]

[tool.semantic_release.changelog]
template_dir = "semantic_template"
changelog_file = "CHANGELOG.md"
exclude_commit_patterns = ["build", "chore", "ci", "docs", "perf", "refactor", "revert", "style"]

[tool.semantic_release.remote]
name = "origin"
type = "gitlab"

Build-system configuration:

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

Logs

logs for the command: semantic-release -vv version --prerelease --no-push:

psr_logs.txt

Additional context

Until PSR 9.6.0 everything works perfectly. We are actually blocked on version 9.5.0.

Copy of your message:

Initially looking at your git history, it looks like PSR is behaving as expected if the commits are parsed with the AngularParser (ie. Conventional Commit standard). build and chore do not trigger a version bump unless otherwise configured. By default only a fix and perf commit type trigger a patch bump.

Separately, I'm not sure what you meant by the statement: releases are based on tag and not on a specific branch. PSR selects the prerelease token & prerelease value and whether or not it should release based on which branch it is on. Common usage of trunk based developers use the default branch to release or use ReleaseFlow branching to have separate branches to perform releases. Ultimately though, PSR will not automatically be able to determine if it should be a prerelease or a regular release if you are releasing these from the same branch. Manual intervention via command line arguments can make this possible.

Thanks for your time.

Best Regards.

[codejedi365]

@JeromeCheviet, I think I know the answer now based on what changed from 9.5 to 9.6. I probably should have made it a breaking change just in case but you live and learn. I am very sorry it messed up your workflow.

If you could try swapping --prerelease with --as-prerelease and it should return to your expected result.

[JeromeCheviet]

Hello @codejedi365 ,

I had tested with --as-prerelease with the version 9.7.2 and it perfectly working.

Thank you for your help.

I'm really sorry because I had read the changelog and seen this new option, but I thought both still worked (and I forgot about it later… ).

So it's my bad. Life is a long learning process :)

Best Regards.