allow to specify non-numeric parts

[thomasf]

Basically I always want the master to not be set to a specific version but a
dev version so that accidental pushes to package repositories happen.

example: bumpversion minor changes version strings from 1.5dev to 1.5, tags
and commits and then changes to 1.6dev and commits that as a separate thing.
There should probably be an option for running an command after tagging for
building and publishing build artifacts.

How this would work with bumpversion patch is at the moment (by me) undefined.
I will get back to detailing this later on, thanks for a great app.

[thomasf]

I just recalled that the monster of project automation tools, maven has a plugin like this:

http://maven.apache.org/maven-release/maven-release-plugin/

However I do not want anything to be like maven so its just for reference :)

[peritus]

Yes, that's something I'd like to support. I just fiddled a bit in /tmp hoping that it works already, but it doesn't.

This part already works:

/tmp/issue43 cat myfile.txt
Version: 1.5.dev

/tmp/issue43 cat .bumpversion.cfg
[bumpversion]
files = myfile.txt
current_version = 1.5.dev
parse = (?P<major>\d+)\.(?P<minor>\d+)(\.(?P<prerel>[a-z]+))?
serialize =
  {major}.{minor}
  {major}.{minor}.{prerel}

/tmp/issue43 bumpversion minor

/tmp/issue43 cat myfile.txt
Version: 1.6

However, when you'd want to bump the prerel part, bumpversion only allows numerical parts for now (and allows you to omit parts that are zero), so what I envision is something along this configuration:

[part:prerel]
values = 
  release
  dev
  alpha
  beta

which would tell bumpversion to count prerel like release, dev, alpha, beta instead of 0, 1, 2, 3, 4, .. then you could do

/tmp/issue43 bumpversion prerel

to bump from 1.6 to 1.6.dev.

[peritus]

Side note 1: I don't think it's a good idea to support "running an command after ...", but support your workflow like

$> bumpversion minor
$> do whatever you --need --to=package and > release
$> bumpversion prerel

so you can use bumpversion at the beginning and the end of the release process.

Side note 2: No, this project won't go the same path as maven's release plugin and its scope is only about bumping versions, nothing else.

[peritus]

Side note 3: I also need to create a "cookbook" documentation page to demonstrate custom workflows/use cases complete with motiviation and config files.

[thomasf]

yeah. keeping it simple with a separate prerel command is better than introducing complexities like having automatic intermediate versions and running commands between them. I can use an ordinary Makefile or similar for those things if they are needed.

[thomasf]

The prerel task should be configurable to ignore tag = True in the config
file since it is often indicating an snapshot package.

[peritus]

How about

$> bumpversion minor
$> # ...
$> bumpversion prerel --no-tag

?

[thomasf]

Yeah. I did think about that as well.
Project specific things like this should maybe be handled by another tool, on the other hand that could said about the vcs tagging features that currently exists in bumpversion as well..

I've just started using this tool today, I might start by writing a simpler makefile that does the tasks around bumpversion and let it sink in for a while,

[peritus]

Had some time to play with the code, here's a working implementation with your example serving as a testcase:

a7bd204#diff-f4bc68ff01eef7bed2f3a64cad7d37caR1163

I as well need to let that sink in for a while to figure out if that can be made simpler from a conceptual point of view and/or from the code I wrote.

You should be able to use

pip install https://github.com/peritus/bumpversion/archive/issue-43.zip#egg=bumpversion-issue-43

to install and play with it. Have fun and let me know what you think.

[thomasf]

I will check it out as soon as I can..

FYI: It is important that 1.2dev is parsed as an pre prelease of 1.2 and that 1.2.dev is something else, At least if you are targeting python packaging using setuptools http://pythonhosted.org/setuptools/setuptools.html#specifying-your-project-s-version

edit: that was misinformation 1.2.dev is allowed.. I remembered the wrong thing.

[peritus]

Hey, made a few adjustments, but basically I added a new test heavily inspired by PEP386 (i know, it's superseded by PEP440, but this is just for illustratory purposes).

bumpversion/tests.py

Lines 1192 to 1249 in 3f1bfce

	def test_python_prerelease_release_postrelease(tmpdir, capsys):
	tmpdir.join("python386.txt").write("1.0a")
	tmpdir.chdir()
	tmpdir.join(".bumpversion.cfg").write(dedent("""
	[bumpversion]
	files = python386.txt
	current_version = 1.0a
	# adapted from http://legacy.python.org/dev/peps/pep-0386/#the-new-versioning-algorithm
	parse = ^
	(?P<major>\d+)\.(?P<minor>\d+) # minimum 'N.N'
	(?:
	(?P<prerel>[abc]|rc) # 'a' = alpha, 'b' = beta
	# 'c' or 'rc' = release candidate
	(?:
	(?P<prerelversion>\d+(?:\.\d+)*)
	)?
	)?
	(?P<postdev>(\.post(?P<post>\d+))?(\.dev(?P<dev>\d+))?)?
	serialize =
	{major}.{minor}{prerel}{prerelversion}
	{major}.{minor}{prerel}
	{major}.{minor}
	[bumpversion:part:prerel]
	optional_value = d
	values =
	dev
	a
	b
	c
	rc
	d
	"""))
	def file_content()
	return tmpdir.join("python386.txt").read()
	main(['prerel'])
	assert '1.0b' == file_content()
	main(['prerelversion'])
	assert '1.0b1' == file_content()
	main(['prerelversion'])
	assert '1.0b2' == file_content()
	main(['prerel']) # now it's 1.0c
	main(['prerel'])
	assert '1.0rc' == file_content()
	main(['prerel'])
	assert '1.0' == file_content()
	main(['minor', '--verbose'])
	assert '1.1dev' == file_content()

So, this configures a part type prerel that instead of counting from 0 to ∞, it goes like dev, a, b, c, rc, d. Also, while for numeric values a trailing 0 can be left off (i.e. 1.0 is a valid representation of 1.0.0), for this part type the optional value is configured to be d, so that's never seen.

Now works like this:

echo 1.0a > file           # -> 1.0a

bumpversion prerel         # -> 1.0b
bumpversion prerelversion  # -> 1.0b1
bumpversion prerelversion  # -> 1.0b2
bumpversion prerel         # -> 1.0c
bumpversion prerel         # -> 1.0rc
bumpversion prerel         # -> 1.0
bumpversion minor          # -> 1.1dev

Do you think that might work for you?

[peritus]

Note to myself: It might be a good idea to allow numeric values to also have a start value other than 0 (in this example one might want to only allow prerels with prerelversion > 0, so we should be able to eliminate the 1.0b -> 1.0b1 bump by configuration).

[peritus]

Merged.

[peritus]

This will be part of the upcoming version 0.5 — which you can install by running

sudo pip install https://github.com/peritus/bumpversion/archive/master.zip#egg=bumpversion-dev

I'd appreciate any testing before the release. Please note the new configuration format (documented in the README)

[thomasf]

I will try it out, have to get to that versioning scheme very soon,

[thomasf]

Ive started to try it out now, I copied the bumpversion.cfg config from this project and it does not work..
I did leave autocommit there so there was an 2.0.0-dev release tag created and thats where things started to go wrong.

The hypen in the -dev tag messes up a string split you have in the latest_tag_info function.

A slightly modified snippet with logging:

  def latest_tag_info(cls):
        try:
            # git-describe doesn't update the git-index, so we do that
            subprocess.check_output(["git", "update-index", "--refresh"])

            # get info about the latest tag in git
            describe_out = subprocess.check_output([
                "git",
                "describe",
                "--dirty",
                "--tags",
                "--long",
                "--abbrev=40",
                "--match=v*",
            ], stderr=subprocess.STDOUT
            ).decode().split("-")
        except subprocess.CalledProcessError:
            # logger.warn("Error when running git describe")
            return {}

        info = {}

        print describe_out
        if describe_out[-1].strip() == "dirty":
            info["dirty"] = True
            describe_out.pop()

        print describe_out
        info["commit_sha"] = describe_out.pop().lstrip("g")
        print describe_out
        info["distance_to_latest_tag"] = int(describe_out.pop())
        print describe_out
        info["current_version"] = describe_out.pop().lstrip("v")

        print describe_out
        # assert type(info["current_version"]) == str
        assert 0 == len(describe_out)

and output

 a01@whale¤%&! bumpversion 
[u'v2.0.0', u'dev', u'2', u'gf176a005e91bfb3addee4cdf096a90fd34f4287a\n']
[u'v2.0.0', u'dev', u'2', u'gf176a005e91bfb3addee4cdf096a90fd34f4287a\n']
[u'v2.0.0', u'dev', u'2']
[u'v2.0.0', u'dev']
[u'v2.0.0']
Traceback (most recent call last):
  File "/home/a00001/.virtualenvs/default/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.5.0', 'console_scripts', 'bumpversion')()
  File "/home/a00001/.virtualenvs/default/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 652, in main
    vcs_info.update(vcs.latest_tag_info())
  File "/home/a00001/.virtualenvs/default/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 148, in latest_tag_info
    assert 0 == len(describe_out)
AssertionError

[thomasf]

sorry for not creating a new ticket, was in a bit of a hurry earlier.

[peritus]

This will do. Looks like the parsing of git describe output does not work correctly for tags containing hypens.

[peritus]

This is tracked in #51 now.