Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
n3tn0de opened this issue Jan 7, 2020 · 7 comments
Open

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

n3tn0de opened this issue Jan 7, 2020 · 7 comments

Comments

@n3tn0de
Copy link

@n3tn0de n3tn0de commented Jan 7, 2020

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

@n3tn0de n3tn0de changed the title Bumping build part when version has no suffix part results suffix being set to 0 (ex.: 0.1.0 -> 0.1.0-0.1)) Bumping build part when version has no suffix part results suffix being set to 0 (ex.: 0.2.0 -> 0.2.0-0.1)) Jan 7, 2020
@n3tn0de n3tn0de changed the title Bumping build part when version has no suffix part results suffix being set to 0 (ex.: 0.2.0 -> 0.2.0-0.1)) Bumping build part when version has no suffix part results suffix being set to 0 (ex.: 0.2.0 -> 0.2.0-0.1)) and no regex mismatch error Jan 8, 2020
@florisla

This comment has been minimized.

Copy link
Collaborator

@florisla florisla commented Jan 8, 2020

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

This comment has been minimized.

Copy link
Author

@n3tn0de n3tn0de commented Jan 8, 2020

Just tried, same behavior, unfortunately.

@florisla

This comment has been minimized.

Copy link
Collaborator

@florisla florisla commented Jan 11, 2020

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

This comment has been minimized.

Copy link
Author

@n3tn0de n3tn0de commented Jan 12, 2020

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

This comment has been minimized.

Copy link
Collaborator

@florisla florisla commented Jan 12, 2020

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

This comment has been minimized.

Copy link
Author

@n3tn0de n3tn0de commented Jan 12, 2020

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

This comment has been minimized.

Copy link
Collaborator

@florisla florisla commented Jan 12, 2020

I understand your use case now.

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

@florisla florisla changed the title Bumping build part when version has no suffix part results suffix being set to 0 (ex.: 0.2.0 -> 0.2.0-0.1)) and no regex mismatch error Don't bump a part if a parent part has its 'final' ('production') value Jan 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.