Open n3tn0de opened 4 years ago
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]
Just tried, same behavior, unfortunately.
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.
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
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.
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.
I understand your use case now.
The behaviour you want could be implemented as an optional feature in a [part:name]
section.
bump2version 0.5.11
Here's my config:
If I try to run
bumpversion build
it will result in0.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...
)ValueError: The part has already the maximum value among ['dev', 'prod'] and cannot be bumped.
,should throw regex mismatch error
Also checked my regex, it works properly https://regexr.com/4rqaj