`part` should not be required if supplying `--new-version`

[brettswift]

This one is pretty basic, but I must be missing something in how people are using this.

Part shouldn't be a required field if you're supplying --new-version. It doesn't make any sense.

If I'm at 0.1.0, and I want to go to 0.1.1, I should be able to do: bumpversion --new-version 0.1.1. I know I can just do bumpversion minor but in this scenario the version is being driven by CI so it may not be sequential.

Anyways, seems like a bug. But this project is old enough that I probably just took some crazy pills. :)

You be the judge!

[ekohl]

I think you're right that this is an odd workflow. A patch would be welcome.

[luckydonald]

Until that is implemented/fixed specifying any part does work. $ bump2version lolwat --new-version=0.1.1

_{^{Bonus: a nice place to hide meme eastereggs in your CI flow.}}

[florisla]

Now that the #68 cleanup is merged (thanks!), I'd like to revisit #57 (the --show argument).

But first I'd like to make part optional. This is already demonstrated in PR #51, but I'd like to combine it with a new approach as described in #63.

The idea: support a named --part argument which will allow for more flexibility in the future.

[luckydonald]

Basically it could look into the config file first which names for parts are there, and after that add arguments to the parser dynamically.

[florisla]

Oh, you mean supporting --major, --minor and --my_part arguments?

I was thinkig to call it --part (literally) which does not require dynamic arguments.

[luckydonald]

I don't see a problem in programming that, really. Also less redundancy when typing it out. bump2version --major=2 --minor=0 --my_part=lol would be easier to type and read then bump2version --part major=2 --part minor=0 --part my_part=lol

[florisla]

That would break for people who have a part called commit, tag or message...

These terms are already taken by existing bump2version arguments.

[ederag]

To me too (as a random user feedback; the following is only what would be natural to me), when --new-version is used, the new version should be exactly the one provided. No smart heuristics (they break too often). An error when the new version is not compatible with the regex would be fine. But then a --force option (#131) would allow to bypass this check and proceed.