Forcing the next version to be a (patch|minor|major) release always uses the highest existing tag · Issue #1392 · python-semantic-release/python-semantic-release · GitHub

Question

When running the version command on a hotfix branch, the new version is based on the tags in the hotfix branch's history. This is expected and what I want.

But when doing the same with --patch, the new version is a patch increase of the highest tag in the repo.

In the log attached below, this gives 1.4.1 as the new version.

Is this expected behavior?

Configuration

Semantic Release Configuration

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

[tool.semantic_release.branches.hotfix]
match = "hotfix/*"
prerelease_token = "rc"
prerelease = false

Additional context

git log --oneline --decorate --graph --all -n 50

* 8e7a550 (HEAD -> hotfix/v1.2.0, tag: v1.2.1) 1.2.1
* 12db328 fix: random stuff
| * d197f21 (tag: v1.4.0, main) 1.4.0
| * bfec9e6 (tag: v1.3.0) 1.3.0
|/  
* cc0ce51 (tag: v1.2.0) 1.2.0
* 3fd623e (tag: v1.1.2) 1.1.2
* 172b8e0 (tag: v1.1.1) 1.1.1
* 433ecf4 fix: random stuff
* 12a4459 (tag: v1.1.0) 1.1.0
* a4ffee4 feat: random stuff
* 0a7c5eb random stuff
* 5817fbd (tag: v1.0.0) 1.0.0
* 027d9c3 Add default PSR config to pyproject.toml
* 88cd67e Add python-semantic-release as dependency
* aca2c9f Initial commit

It is the expected behavior from some flawed code! I identified a similar bug with the approach of prereleases and fixed that a while back but it's still exists around the tags_and_releases() function in which the force bump relies on. I have a larger refactor that fixes the internal function but I didn't realize it was connected to the force bump until you opened this issue. Thanks!

Thank you, great to hear a fix is on the roadmap!

"Larger refactor" sounds like the fix might take a while to be mainlined though, so in the meantime, I'll be using the following hack...
I'm sure it is misbehaving in some cases and I only dipped a toe into the codebase, so this is lacking nuance, but so far it seems to work for my specific use case:

# cli/commands/version.py
# Remove extra handling for forced_level_bump, pass it to next_version instead
    with Repo(str(runtime.repo_dir)) as git_repo:
        new_version = next_version(
            repo=git_repo,
            # ...
            forced_level_bump=forced_level_bump,
        )

# version/algorithm.py
# Early out from next_version on forced_level_bump
def next_version(
    repo: Repo,
    # ...
    forced_level_bump: LevelBump | None = None,
) -> Version:

    # ...

    # Step 3A. Early exit if we're force bumping the version
    if forced_level_bump and latest_version:
        next_version = latest_version.bump(forced_level_bump)
        logger.info(f"Forced bump from {latest_version} to {next_version}")
        return next_version

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

This also seems to affect --prerelease

This is with both 9.21.1 and 10.5.3.

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

Forcing the next version to be a (patch|minor|major) release always uses the highest existing tag · Issue #1392 · python-semantic-release/python-semantic-release · GitHub

Repository navigation

Forcing the next version to be a (patch|minor|major) release always uses the highest existing tag #1392

Question

Configuration

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Forcing the next version to be a (patch|minor|major) release always uses the highest existing tag · Issue #1392 · python-semantic-release/python-semantic-release · GitHub

Repository navigation

Forcing the next version to be a (patch|minor|major) release always uses the highest existing tag #1392

Description

Question

Configuration

Additional context

Activity

codejedi365 commented on Dec 13, 2025

somnolik commented on Dec 14, 2025

github-actions commented on Mar 15, 2026

nwns commented on Jul 3, 2026

github-actions commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions