--new-version: 4.0.1.dev2 becomes 4.0 instead of 4.0.1

[luckydonald]

I am currently at version 4.0.1.dev2, and want to proceed to non-dev 4.0.1. Instead I end up with 4.0.

Reproduction

The command is $ bump2version dev --new-version 4.0.1,
the code is luckydonald/pytgbot@85bf22.

Other issues

This might probably be related to #30, and could benefit from #22.

Details

Here is the full output, fully how it at some point just changes the version number to be wrong.

$ bump2version --verbose --dry-run --new-version 4.0.1 dev
Reading config file .bumpversion.cfg:
[bumpversion]
current_version = 4.0.1.dev2
commit = True
tag = True
parse = (?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?
serialize = 
        {major}.{minor}.{patch}.{pre}.dev{dev}
        {major}.{minor}.{patch}.dev{dev}
        {major}.{minor}.{patch}
        {major}.{minor}

[bumpversion:part:pre]
optional_value = final
first_value = final
values = 
        a
        b
        rc
        final
        post

[bumpversion:file:pytgbot/__init__.py]

[bumpversion:file:setup.py]

[bumpversion:file:README.md]


Parsing version '4.0.1.dev2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?'
Parsed the following values: dev=2, major=4, minor=0, patch=1, pre=final
Attempting to increment part 'dev'
Values are now: dev=3, major=4, minor=0, patch=1, pre=0
Dry run active, won't touch any files.
Parsing version '4.0.1' using regexp '(?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?'
Parsed the following values: dev=0, major=4, minor=0, patch=0, pre=final
New version will be '4.0.1'
Asserting files pytgbot/__init__.py, setup.py, README.md contain the version string:
Found '4.0.1.dev2' in pytgbot/__init__.py at line 5: __version__ = "4.0.1.dev2"
Found '4.0.1.dev2' in setup.py at line 10:     name='pytgbot', version="4.0.1.dev2",
Found '4.0.1.dev2' in README.md at line 1: ### Version [4.0.1.dev2 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
Would change file pytgbot/__init__.py:
--- a/pytgbot/__init__.py
+++ b/pytgbot/__init__.py
@@ -3,7 +3,7 @@
 from .bot import Bot
 
 __author__ = 'luckydonald'
-__version__ = "4.0.1.dev2"
+__version__ = "4.0"
 __all__ = ["api_types", "bot", "Bot"]
 VERSION = __version__
 
Would change file setup.py:
--- a/setup.py
+++ b/setup.py
@@ -8,7 +8,7 @@
 long_description = """A Python module that connects to the Telegram bot api, allowing to interact with Telegram users or groups."""
 
 setup(
-    name='pytgbot', version="4.0.1.dev2",
+    name='pytgbot', version="4.0",
     description='Connect to the Telegram Bot API, receive and send Telegram messages.',
     long_description=long_description,
     # The project's main homepage.
Would change file README.md:
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # pytgbot - Telegram Bot API [`4`.`0`](https://core.telegram.org/bots/api)
-### Version [4.0.1.dev2 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
+### Version [4.0 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
 ###### Python module to access the telegram bot api.
 
 Native python package with a pure Python interface for the [Telegram Bot API](https://core.telegram.org/bots).
Would write to config file .bumpversion.cfg:
[bumpversion]
current_version = 4.0.1
commit = True
tag = True
parse = (?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?
serialize = 
        {major}.{minor}.{patch}.{pre}.dev{dev}
        {major}.{minor}.{patch}.dev{dev}
        {major}.{minor}.{patch}
        {major}.{minor}

[bumpversion:part:pre]
optional_value = final
first_value = final
values = 
        a
        b
        rc
        final
        post

[bumpversion:file:pytgbot/__init__.py]

[bumpversion:file:setup.py]

[bumpversion:file:README.md]


Would prepare Git commit
Would add changes in file 'pytgbot/__init__.py' to Git
Would add changes in file 'setup.py' to Git
Would add changes in file 'README.md' to Git
Would add changes in file '.bumpversion.cfg' to Git
Would commit to Git with message 'Bump version: 4.0.1.dev2 → 4.0.1'
Would tag 'v4.0.1' with message 'Bump version: 4.0.1.dev2 → 4.0.1' in Git and not signing

[ziima]

Encountered a similar problem when I tried to set up support for release candidates.

I came up with

[bumpversion]
current_version = 3.0
commit = True
tag = True
tag_name = {new_version}
parse = (?P<major>\d+)\.(?P<minor>\d+)(?P<rc>.*)
serialize =
    {major}.{minor}{rc}
    {major}.{minor}

[bumpversion:part:rc]
optional_value = final
values =
    rc1
    rc2
    rc3
    rc4
    rc5
    final

But it has troublesome usage. For bump 3.0 -> 3.1rc1 I need to bump minor, and for bump 3.1rc5 -> 3.1 I need to bump rc which is counterintuitive.

I'd like to bump rc for 3.0 -> 3.1rc1 and bump minor (or something like final) for 3.1rc1 -> 3.1.

[drastawi]

@luckydonald I just ran into the same thing. You probably already figured it out by now, but note that your parsing only detects 4.0.1. and not 4.0.1. You should move the dot to be a part of the optional string...?(.(dev)?(?....

@c4urself it would be great if the repo had instructions or examples of how to write these "parsing regex" strings for serializers with multiple options, e.g.

        {major}.{minor}.{patch}.dev{dev}
        {major}.{minor}.{patch}

It's not that easy to figure out what the string should be without reading the code in detail.

[luckydonald]

@drastawi I did not so far 😅

You're right indeed.

[luckydonald]

However it still shouldn't bump from 4.0 to 4.0...

[drastawi]

@luckydonald, I think you are trying to bump to an "invalid" version, so the code just tries its best guess, and I think it's the right choice since there is no patch that the serializer could recognize.

After I moved the dot to dev/pre part of the serializer, bumping the patch worked very well for me.

[florisla]

What happens is, bump2version parses 4.0.1 using the regex and detects 4.0 due to a bug in the regex.

And 4.0 is a valid version since serialize contains {major}.{minor}. It thinks you ask for 4.0 and internally that becomes 4.0.0 with pre=final and dev=0.

We can't block bumping from 4.0.1 to 4.0.0 because bumping down is valid in some cases (e.g. move back from 4.0.0 to 3.9.9).