support prereleases

Here is the workflow I’m following for my project (assuming last release is 3.11) ‘master’ branch is for stable releases, ‘next’ is for development.

On ‘next’:

• First, alpha release: 3.12a1 to start implementing exciting new features
• When all new features are implemented: first release candidate: 3.12rc1
• Fix bugs found during beta-testing: 3.12rc2
• (optional: 3.12rc3, 3.12rc4 … until all blocking bugs are fixed)
• Final release: 3.12 (merge ‘next’ into ‘master’)

On ‘master’;

• Bugs found after 3.12 was released, release 3.12.1
• Optional, 3.12.3, 3.12.4…,

This version scheme is modeled after PEP440

Here’s what I’ve tried:

[bumpversion]
current_version = 3.12a1
files = setup.py cmake/qibuild/version.cmake doc/source/conf.in.py python/qisys/main.py
message = qibuild {new_version}
commit = True
tag = True
parse = (?P<major>\d+)                             # major: 3.12 -> 3
        \.
        (?P<minor>\d+)                             # minor 3.12 -> 12
        (\.(?P<patch>\d+))?                        # either a maintenance release 3.12.1 ...
        ((?P<release>a|rc)(?P<rel_num>\d+))?       # or a rc, or an alpha 3.12a1, 3.12rc2
serialize =
  {major}.{minor}
  {major}.{minor}.{patch}
  {major}.{minor}{release}{rel_num}

[bumpversion:part:release]
values =
  a
  rc

But then I get:

$ bump_version rel_num
Parsing version '3.12a1' using regexp '(?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+))?((?P<release>a|rc)(?P<rel_num>\d+))?'
Parsed the following values: major=3, minor=12, patch=0, rel_num=1, release=a
Attempting to increment part 'rel_num'
Values are now: major=3, minor=12
Did not find key u'patch' in <bumpversion.Version:major=3, minor=12> when serializing version number
Opportunistic finding of new_version failed: Did not find key u'patch' in <bumpversion.Version:major=3, minor=12> when serializing version number
...
bumpversion: error: argument --new-version is required

Digging in the source code, I suspect the problem is somewhere near:

class VersionConfig(object):

    # ....

    def order(self):
        # currently, order depends on the first given serialization format
        # this seems like a good idea because this should be the most complete format
        return self._labels_for_format(self.serialize_formats[0])

But maybe there’s something I’ve missed in the documentation…

[dmerejkowsky]

In case this helps, we’ve built an alternative called tbump

Prelease support looks like this:

[version]
current = "1.6.0"

regex = '''
  (?P<major>\d+)
  \.
  (?P<minor>\d+)
  \.
  (?P<patch>\d+)
  (
    -
    (?P<lifecycle>alpha|beta|r)
    (?P<release>\d+)
  )?

And then you can use tbump 1.6.1. or tbump 1.6.0-r1

Cons: you have to type the whole version number on the command line instead of the ‘part’ you want to bump

Pros: the implementation is much simpler and supports many use cases.

[webyneter]

The weird thing is, given

[bumpversion]
current_version = 0.1.0
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<pre>\d+)\.(?P<prenum>\d+))?
serialize =
	{major}.{minor}.{patch}-{pre}.{prenum}
	{major}.{minor}.{patch}

(note the absence of explicit pre and prenum parts declaration, hence both are being implicitly set to default numeric part definitions under the hood), I can

0.1.0 → bumpversion pre→ 0.1.0-1.0 → bumpversion prenum → 0.1.0-1.1 → bumpversion prenum → 0.1.0-1.2 → bumpversion major → 1.0.0.

However, whenever custom values are set in any of extra part definitions, -{pre}.{prenum} gets appended no matter what part is bumped.