semantic-release version --prerelease does not force a prerelease version bump.

[css-optivoy]

The problem

semantic-release version --prerelease does not force a prerelease version bump:

$ git log
commit 2f01c54100ae5a63020e267a397221f088f927e3 (HEAD -> bump)
Author: css
Date:   Tue Jul 18 10:04:41 2023 +0200

    build(meh): Blah

commit bfed5b9fda67e7ef3e251c18860f48b59798b7a8 (tag: 0.27.7-dev.3)
Author: semantic-release <semantic-release>
Date:   Mon Jul 17 11:33:02 2023 +0000

    0.27.7-dev.3
    
    Automatically generated by python-semantic-release

$ semantic-release version --prerelease
[...]
           WARNING  [semantic_release.cli.commands.version] WARNING version.version: Forcing prerelease due to '--prerelease' version.py:247
                    command-line flag     
           INFO     [semantic_release.version.algorithm] INFO algorithm.tags_and_versions: found 303 previous tags           algorithm.py:55
           INFO     [semantic_release.version.algorithm] INFO algorithm.next_version: Found 106 full releases (excluding    algorithm.py:245
                    prereleases)                                                                                                            
           INFO     [semantic_release.version.algorithm] INFO algorithm.next_version: The last full release was 0.27.6,     algorithm.py:267
                    tagged as '0.27.6'                                                                                                      
           INFO     [semantic_release.version.algorithm] INFO algorithm.bfs: found latest version in branch history:         algorithm.py:91
                    '0.27.6' (f5dbb72)                                                                                                      
           INFO     [semantic_release.version.algorithm] INFO algorithm._bfs_for_latest_version_in_history: the latest      algorithm.py:110
                    version in this branch's history is 0.27.6                                                                              
           INFO     [semantic_release.version.algorithm] INFO algorithm.next_version: The last full version in this         algorithm.py:291
                    branch's history was 0.27.6                                                                                             
           INFO     [semantic_release.version.algorithm] INFO algorithm.next_version: The type of the next release release  algorithm.py:368
                    is: no_release                                                                                                          
           INFO     [semantic_release.version.algorithm] INFO algorithm.next_version: No release will be made               algorithm.py:370
0.27.7-dev.3
           INFO     [semantic_release.version.algorithm] INFO algorithm.tags_and_versions: found 303 previous tags           algorithm.py:55
No release will be made, 0.27.7-dev.3 has already been released!

Expected behavior

Running the above should produce a new prerelease version.

Environment

$ semantic-release --version
semantic-release, version 8.0.1

Additional context

From a quick glance at the code it looks like it might be the logic around here:

python-semantic-release/semantic_release/cli/commands/version.py

Lines 246 to 271 in 2129b72

	if force_prerelease:
	log.warning("Forcing prerelease due to '--prerelease' command-line flag")
	elif force_level:
	log.warning(
	"Forcing prerelease=False due to '--%s' command-line flag and no '--prerelease' flag",
	force_level,
	)
	if force_level:
	level_bump = LevelBump.from_string(force_level)
	log.warning(
	"Forcing a %s level bump due to '--force' command-line option", force_level
	)
	new_version = version_from_forced_level(
	repo=repo, level_bump=level_bump, translator=translator
	)
	# We only turn the forced version into a prerelease if the user has specified
	# that that is what they want on the command-line; otherwise we assume they are
	# forcing a full release
	new_version = (
	new_version.to_prerelease(token=translator.prerelease_token)
	if prerelease
	else new_version.finalize_version()
	)

Setting any of --major, --minor and --patch will set force_level, but setting --prerelease will set force_prerelease, which does not appear to set the level_bump.

Adding force_level = "PRERELEASE_REVISION" here, makes the logic work as expected:

python-semantic-release/semantic_release/cli/commands/version.py

Lines 246 to 247 in 2129b72

	if force_prerelease:
	log.warning("Forcing prerelease due to '--prerelease' command-line flag")

[bernardcooke53]

Hey @css-optivoy - The intention with --prerelease is to force the next version to be a prerelease if there's one to be made - I can see you're getting "no release will be made" as output. What have you set for your commit_parser_options?

By default commit_parser_options.patch_types = ["fix", "perf"], so because "build" isn't in there PSR thinks there's no commits since the last release that should trigger a new one - if you want "build" to trigger a patch release you'll need to add it to commit_parser_options.patch_types

[css-optivoy]

The intention with --prerelease is to force the next version to be a prerelease if there's one to be made

Thank you for clarifying.

Unfortunately that is surprising because:

1. This appears to be new, breaking change behaviour in v8:

$ git log
commit 195afb360e7b6825a279abe431162ae5ec249c96
Author: css
Date:   Wed Jul 19 07:47:48 2023 +0200

    build(A): B

commit 578fe4dca303c14ca0357fd6d161c5b10e1397e5 (tag: 0.27.7-dev.4, origin/main, main)
Author: semantic-release <semantic-release>
Date:   Tue Jul 18 08:57:11 2023 +0000

    0.27.7-dev.4
    
    Automatically generated by python-semantic-release

$ poetry show python-semantic-release                         
 version      : 7.34.6  

$ semantic-release version --prerelease
Creating new version
Current version: 0.27.7-dev.4, Current release version: 0.27.6
Bumping with a patch version to 0.27.7-dev.5

2. That makes --prerelease special, and different from all the other level bumps, --major, --minor, --patch.
   As seen in the code snippet above, the other flags do force a version bump regardless, and --prerelease is the only one that doesn't. And this difference is not mentioned in any form in the help:

$ semantic-release --version
semantic-release, version 8.0.1
$ semantic-release version --help
[...]
Options:
  --prerelease                    Force the next version to be a prerelease
  --major                         force the next version to be a major release
  --minor                         force the next version to be a minor release
  --patch                         force the next version to be a patch release

We are currently relying on the old behaviour for all our repos, so I've unfortunately had to downgrade all of them to v7 when this started breaking everything.
Is there some way to get the old behaviour with v8?

I see commit_parser_options.patch_types might be a workaround of sorts. But it still doesn't completely solve it, as we specifically want to force prerelease - even if there are no tags that match anything in particular.

[bernardcooke53]

Hi @css-optivoy

I've had a re-read of the docs and the source code, I responded in a hurry to this yesterday which was probably a bad idea - something about the notion of "if there's one to be made" didn't sit right with me.

It turns out that that would be really strange and inconsistent - and that's not how I wrote the code, nor how I documented it, and it's a bug/break because it should be consistent.

I still think you need to add in those patch_types, but as you pointed out even in the help text - --prerelease is a force.

I've raised #647 which should put these options straight - really what --prerelease is doing should be a new feature, --as-prerelease, and the --prerelease flag should force as it used to. I'd be grateful if you could have a glace over the PR

[css-optivoy]

Thank you.

I'd be grateful if you could have a glace over the PR

I've left some thoughts on #647 (comment)

I still think you need to add in those patch_types

A bit of an aside, but is there a prerelease_types? I couldn't seem to find an exhaustive list of options in the docs, and no mention of a prerelease_types.

I think what we'd want is essentially commit_parser_options.prerelease_types = ["*"]

[bernardcooke53]

Have responded on the PR - thanks for having a look.

To your aside - there's no prerelease_types, any allowed_tag is eligible to be made to a prerelease.
It would be possible to write a commit parser that always parses at least a prerelease revision, that would reflect here.

[codejedi365]

🎉 This issue has been resolved in version 9.6.0 🎉

The release is available on:

• PyPi package
• GitHub release