add support to keep values of specific parts (eg. metadata used in semver) #80

[martinm82]

I have hacked this a bit together and would like to get some guidance from you guys how to implement this better.

[florisla]

I would call this independent, because the metadata part can still change (if you change it explicitly).

[c4urself]

hmm, I'm not sure if I would grok exactly what independent means at a first glance. Changing it explicitly is out-of-scope of bumpversion and in the context of bumpversion keep_value: True seems more straightforward.

[martinm82]

I have to agree with @c4urself as I as well wouldn't know how to interpret independent. But I am still open for other suggestions.

[martinm82]

Ok, now I see where this independent actually comes from (ADVbumpversion). If you plan to merge both forks again I would be find with independent.
Are there any plans to do that?

[florisla]

Beware, bump2version will remove these commented lines on the next bump!

[florisla]

Related issue: #80

[dalbani]

I've just discovered bump2version when looking for a tool to bump version of Helm charts.
And I have a question which may be related to this merge request: I would like to be able to set an (optional) static -SNAPSHOT suffix qualifier to a version. Kind of like Maven snapshot artifact are named.
For example:

• Starting point: 0.0.1-SNAPSHOT.
• Then be able to release the chart as the developer sees fit, for example 0.0.1 or even 0.1.0, etc.
• And finally afterwards the version would be set back to a (configurable) -SNAPSHOT version.

Basically kind of how the jgitflow plugin works, but not tied to a pom.xml.
Is there a way to accomplish that with bump2version? Would this keep_value functionality be needed then?
Thanks!

[martinm82]

Question is, is this implementation kind of acceptable or possibly causing some side-effects?

[martinm82]

• Starting point: 0.0.1-SNAPSHOT.
• Then be able to release the chart as the developer sees fit, for example 0.0.1 or even 0.1.0, etc.

Yes, that is possible with this tool.

• And finally afterwards the version would be set back to a (configurable) -SNAPSHOT version.

You mean setting it back to 0.0.2-SNAPSHOT or 0.1.1-SNAPSHOT, right?

[dalbani]

@martinm82
Yes, that's what I meant.
Actually I think I've managed to have a working configuration (without this pull request):

[bumpversion]
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<release>[A-Z]+))?
serialize = 
	{major}.{minor}.{patch}-{release}
	{major}.{minor}.{patch}
search = version: {current_version}
replace = version: {new_version}
current_version = 0.1.0-SNAPSHOT

[bumpversion:part:release]
optional_value = PRODUCTION
values = 
	SNAPSHOT
	PRODUCTION

But, unless I'm doing it wrong, I had to add this unused PRODUCTION to make it work?!?
Otherwise I got such an error:

ValueError: The part has already the maximum value among ['SNAPSHOT'] and cannot be bumped.

It is what this pull request is (indirectly) going to fix?

[martinm82]

@dalbani yes this is the way to do that. It is basically the same as in all other implementations (eg. https://github.com/peritus/bumpversion).

BTW, for what you want to achieve you don't need the changes from this PR.

[dalbani]

@martinm82
OK, good to know. But don't you find strange that this PRODUCTION entry has to be added, even though it's never used?!?

[ottomata]

[edited comment]

Sorry, spoke way too soon! The copy/pasted parse regex was not matching my -dev release name (and my previous iterations had the wrong optional value specified.) I have it working, carry on, sorry for the noise!