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 https://github.com/commitizen-tools/commitizen/pull/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).

[woile]

Sounds good to me, we can start with a draft. What kind of conditions were you thinking about @manang ? I think there should be no problem with this

[manang]

I'm interested to this feature, but what I'm thinking is: take the last commit message, parse it, show the same menu like "cz commit" but with precompiled fields and that's all.

[adamcunnington-gdt]

@manang not sure what you're talking about there - has nothing to do with this feature.

This feature is about allowing a user to explicitly manually bump a version using cz bump. Nothing to do with commit messages.

[manang]

Hi, sorry, I did not read the entire issues and I was thinking about another feature that I proposed (cz amend)

so...about that...do you have hints to start the development? Thanks

[Lee-W]

So from what I understand this feature is about providing another argument that can update version across all version files.

$ cat version.py
1.0.0
$ cat pyproject.toml | grep __version__
__version__ = "1.0.0"

$ cz bump --some-arg 1.5.3

$ cat version.py
1.5.3
$ cat pyproject.toml | grep __version__
__version__ = "1.5.3"

If my understanding is correct, what we do is to add an argument to https://github.com/commitizen-tools/commitizen/blob/master/commitizen/commands/bump.py and call this function https://github.com/commitizen-tools/commitizen/blob/master/commitizen/bump.py#L142

[adamcunnington-mlg]

@manang ?

[manang]

Hi, sorry, it is bank holiday and I'm not at home. I will contact you this week about this feature. See you Angelo

[adamcunnington-mlg]

@manang i take it that are you not picking this up?

[manang]

sorry, nono, I need to finish it. this week end I will push the modification. sorry for the delay, but I'm busy for the last things before Christmas. Angelo

[adamcunnington-mlg]

@manang I guess you are not ever getting around to this, right?

[jakob-keller]

I would also love to see this feature implemented!

[adamhoffstein]

So I take it this isn't happening?

[jakob-keller]

So I take it this isn't happening?

It's been implemented and shipped since 2.34.0.