Don't bump a part if a parent part has its 'final' ('production') value

[n3tn0de]

bump2version 0.5.11

Here's my config:

[bumpversion]
current_version = 0.2.0
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<suffix>[a-z]+))?(\.(?P<build>\d+))?
serialize = 
	{major}.{minor}.{patch}-{suffix}.{build}
	{major}.{minor}.{patch}-{suffix}
	{major}.{minor}.{patch}

[bumpversion:part:suffix]
optional_value = prod
values = 
	dev
	prod

[bumpversion:file:VERSION]

If I try to run bumpversion build it will result in 0.2.0-0.1 which it should not. It should throw error similar to the suffix part (ValueError: The part has already the maximum value among...)

bumpversion part	current_version	new_version	works correctly?
build	0.1.0-dev	0.1.0-dev.1	✅yes
suffix	0.1.0-dev.1	0.1.0	✅yes
minor	0.1.0	0.2.0-dev	✅yes
build	0.2.0-dev	0.2.0-dev.1	✅yes
suffix	0.2.0-dev.1	0.2.0	✅yes
build	0.2.0	0.2.0-0.1	❌ should throw error
suffix	0.2.0-0.1	n/a	❌throws ValueError: The part has already the maximum value among ['dev', 'prod'] and cannot be bumped., should throw regex mismatch error
build	0.2.0-0.1	0.2.0-0.1	❌ should throw regex mismatch error

Also checked my regex, it works properly https://regexr.com/4rqaj

[florisla]

Perhaps bump2version is not fully aware about the build part at all times?

Can you try to add this to your config and check again?

[bumpversion:part:build]

[n3tn0de]

Just tried, same behavior, unfortunately.

[florisla]

Looking at your table again, it seems to me that this is actually standard behavior and not a bug.

Basically, you want to make build values larger than zero invalid in case suffix is prod, right?

Considering a part value to be 'final' is a feature that's not present at the moment.

Most people don't need this feature either I think. The common practice is to bump suffix to prod when releasing, and bump patch or minor immediately after that. So the VCS heads never contain prod versions. prod solely occurs in the tags.

[n3tn0de]

Still, if you accidentally bump build part on prod version instead of suffix, you break the scheme and need to roll back commit and delete the tag.

And I disagree on this

and bump patch or minor immediately after that

You don't know what sort of changes (potentially compat. breaking) will be added, so bumping major, minor or patch immediately is against semver rules.

Any suffixes (nightly, qa, etc.) and build parts are, of course, optional, they just help tell apart different builds of your software. You can also use commit hashes as suffix to tell apart the builds.

Still, major, minor or patch should be bumped after features and bugfixes commits pass PRs

[florisla]

You're right, but you can't keep using 2.0.0 in master either -- that would mean multiple commits share the same prod version. That also violates semver.

Bumping tag forces suffix to be dev. Later, at release time (or when committing impactful changes), you can still decide to bump major or minor as needed.

[n3tn0de]

Semver generally concerns releases, not commits, but I see your reasoning.

But this usually solved one way or another with develop/feature branches and/or CI/CD tools, for example, by adding branch name and commit hash to version string in compiled files, if commit doesn't have a tag and/or not in the master branch.

Anyway, I think we went off topic on this.

Bumping build part on prod should either result in error, 0.2.0-dev.1 or 0.2.0-dev to comply with the scheme.

[florisla]

I understand your use case now.

The behaviour you want could be implemented as an optional feature in a [part:name] section.