Starting a part at 0

[televi]

I have a parse string of

parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)([-.]dev(?P<build>\d+))?

that serializes as

serialize =
    {major}.{minor}.{patch}.dev{build}
    {major}.{minor}.{patch}

The build part is defined as

[bumpversion:part:build]
first_value = 0

When I have a current version of A.B.C and do a bumpversion build, I would expect to get A.B.C.dev0. What I actually get is A.B.C.dev1.

What seems to be happening is that the build part is getting a default value when it is parsed and bumpversion doesn't see that - it thinks the value is an actual value. It then seems to simply ignore the first_value for the build part (as it doesn't think it is starting new). That makes it impossible for me to start a user defined part at 0.

Here's a snippet of the output from --dry-run --verbose

Parsing version '3.14.0' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)([-.]dev(?P<build>\d+))?'
Parsed the following values: build=0, major=3, minor=14, patch=0
Attempting to increment part 'build'
Values are now: build=1, major=3, minor=14, patch=0
Dry run active, won't touch any files.
Parsing version '3.14.0.dev1' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)([-.]dev(?P<build>\d+))?'
Parsed the following values: build=1, major=3, minor=14, patch=0
New version will be '3.14.0.dev1'

The behavior I was expecting was the following and seemed to be reasonable based on what I saw for non-user defined parts:

bumpverion part	current_version	new_version	works now?
build	A.B.C	A.B.C.dev0	no (get dev1)
build	A.B.C.devN	A.B.C.devN+1	yes
patch	A.B.C	A.B.C+1	yes
patch	A.B.C.devN	A.B.C+1	yes
minor	A.B.C	A.B+1.0	yes
minor	A.B.C.devN	A.B+1.0	yes
major	A.B.C	A+1.0.0	yes
major	A.B.C.devN	A+1.0.0	yes

From the above, it seems like the only thing that doesn't start at zero when it "should" on bumps is user defined parts.

[televi]

Digging a bit deeper into the code, I think the problem is here in VersionPart.value().

When the RE is parsed, from the above example, build will have a value of None. What the above code does, however, is translate None into optional_value (which I don't think is correct - it should probably be first_value if anything). That means the fact that this part was not present is lost (the remainder of the methods in VersionPart all see to use the value() property so they'll not see None.

[florisla]

I think 0 is the first value by default, so it probably works better if you remove this line altogether?

first_value = 0

[florisla]

Upon re-reading your table, I think this is designed behavior of bump2version.

When your version is A.B.C, the value of build implied is 0. Value zero by default is optional_value so that means A.B.C.dev0 is serialized as A.B.C.

The build number only surfaces when it becomes 1 or higher.

It seems like what you want to do is this:

[bumpversion:part:build]
first_value = -1
optional_value = -1

So that the first bump of build will increment its value from -1 to 0, and 0 will be serialized.

However using negative numbers is not possible currently.

Your only option is to do this instead

[bumpversion:part:build]
optional_value = n_a
values =
    n_a
    dev0
    dev1
    dev2
    dev3
    dev4

etc.

with this parse:

parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)([-.](?P<build>dev\d+))?

Is there a particular reason you want your build numbers to start at 0 and not at 1?

[florisla]

Another way to use optional_value:

[bumpversion:part:build]
first_value = 0
optional_value = final

But this does not get you all the way. A.B.C is represented internally as A.B.C.devfinal. Bumping build from there is not possible, as 'final' is considered to be the 'highest' possible value for build.

So bump2version makes some assumptions which are not compatible with your desired flow.

The assumption: You use version A.B.C.dev[x] during development, and release A.B.C when development is done.

Can you elaborate on why you want to bump to A.B.C first, and afterwards bump to A.B.C.dev0 ?