Manually bump entire version, not just manually specify which part to increment

[adamcunnington-gdt]

The docs state that the version can be manually bumped but I believe this is incorrect as there's no other mention of this in the docs or in the CLI help beyond --increment {MAJOR,MINOR,PATCH} which is merely specifying the part to auto-increment.

Why do I want to manually specify the version to bump to? Well, I don't but unfortunately, dev versions are not supported - but I still want to make use of commitizen's version-updating inside of files. Otherwise, I will need to use a separate tool in conjunction, such as bumpversion.

I want to be able to do cz bump 1.0.1 for example (optional positional arg or --manual <foo> option would be fine).

A question on this though - whilst commitizen does not support dev versions, will it still be able to successfully parse a PEP440-compatible version that includes a dev version, for the sake of bumping? I.e. will commitizen be able to bump 1.0.1.dev0+foo.bar.baz to 1.0.2 or 1.1.0 etc.?

And the ultimate related question - is there any planned support for dev versions?

[adamcunnington-gdt]

@Lee-W grateful for just your quick top-of-the-head thoughts here. Essentially:

• Can you confirm my understanding is correct.
• Can you indicate how willing you would be to support this?

[Lee-W]

I notice there's a discussion on #150 . Do you think they're related?

[adamcunnington-gdt]

Not really, no.
#150 is about a specific scenario in which the tool can't bump.

This issue is about supporting explicit manual bumping - i.e. not relying on any auto-bumping at all.
I think this is a critical feature because it provides a workaround for every issue where auto-bumping doesn't work / doesn't produce desired result.

[Lee-W]

Can you confirm my understanding is correct.

Yes, I think your understanding is correct.

Can you indicate how willing you would be to support this?

I'm okay with it if someone wants to implement this. Also, we'll need @woile 's thought on this

A question on this though - whilst commitizen does not support dev versions, will it still be able to successfully parse a PEP440-compatible version that includes a dev version, for the sake of bumping? I.e. will commitizen be able to bump 1.0.1.dev0+foo.bar.baz to 1.0.2 or 1.1.0 etc.?

So #150 doesn't relate to this either?

[adamcunnington-gdt]

Thanks. To your last point, you are right, #150 does relate to that. I answered my own question there though - I tried to see if I could bump a PEP440-compatible version to a SemVer-compatible version and that works at least - so I can't use commitizen to create a .devN+... version, but it can at least read it when it comes to regex replace to bump with a release version.

[woile]

A question on this though - whilst commitizen does not support dev versions, will it still be able to successfully parse a PEP440-compatible version that includes a dev version, for the sake of bumping?

We use the python packaging version parser, so it should work I guess.
And I'd like to make use of poetry's semver at some point.

I like this proposal: cz bump 1.0.1, it's quite straightforward and similar to what cz changelog is going to support after #400

[manang]

can we discuss how to implement this feature?
I can implement, if you agree.
Let me know

[adamcunnington-gdt]

I assume that is directed to @woile or @Lee-W but this sounds pretty trivial... adding a parameter to the cli handler, and then passing the value to whatever function does the replacement in files - which is existing functionality.

[manang]

ok, but, for example, there are exclusions with the other commands? can we do a list of conditions to create, after, the tests?
Thanks

[adamcunnington-gdt]

@woile @Lee-W I guess @manang is waiting for a response here (assuming they are still interested in contributing this).