peritus / bumpversion Goto Github PK

During development it is useful to track release candidate versions. Bump version should support bumping major, minor, patch and release_candidate versions.

After seeing the request to open an issue if this tool does not support every aspect of bumping versions in your development workflow, I figured I'd leave this here.

I have a CHANGELOG file that looks like this:

0.3.0 [unreleased]
    - add exciting feature
    - fix annoying bug
    - improve docs

0.2.0 [2013-01-19]
    - add boring feature
    - fix severe bug

It would be great if, when bumping to 0.3.0, [unreleased] was automatically replaced with the current date.

Many projects use a versioning scheme that allows for version numbers without a patch (e.g. 1.0 or 2.7) and these versions are equivalent to the patch version 0.

Could bumpversion support this convention as an opt-in feature?

I imagine something like a config var "initial_patch_number" which could be 0 or None, and defaults to 0. None would mean the patch is omitted initially. Theoretically, the value could also take 1. Or the var could be a simple flag "initial_patch_is_null".

I would suggest the same for the minor version, except that the VCS clients don't work well with tags that aren't simple digits.

bumpversion tries to convert the latest git rev hash to an int:

Traceback (most recent call last):
  File "/home/shokah/.virtualenvs/TPB/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.6', 'console_scripts', 'bumpversion')()
  File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 243, in main
    vcs_info.update(vcs.latest_tag_info())
  File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 85, in latest_tag_info
    info["distance_to_latest_tag"] = int(describe_out.pop())
ValueError: invalid literal for int() with base 10: 'g41e1dd17c20e81324102c859b89761b8e2f2f666'

I tried the version installed by pip (0.5) and from src (0.5.1-dev, installing manually) and I am getting a similar error either running with arguments or using a configuration file.

With version 0.5 I get

Traceback (most recent call last):
  File "/usr/local/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.5.0', 'console_scripts', 'bumpversion')()
  File "/Library/Python/2.7/site-packages/bumpversion/__init__.py", line 647, in main
    vcs_info.update(vcs.latest_tag_info())
  File "/Library/Python/2.7/site-packages/bumpversion/__init__.py", line 143, in latest_tag_info
    assert 0 == len(describe_out)
AssertionError

and on version 0.5.1-dev

Traceback (most recent call last):
  File "/usr/local/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.5.1-dev', 'console_scripts', 'bumpversion')()
  File "build/bdist.macosx-10.9-intel/egg/bumpversion/__init__.py", line 657, in main

  File "build/bdist.macosx-10.9-intel/egg/bumpversion/__init__.py", line 143, in latest_tag_info

AssertionError

I am using latest version of bumpversion. When I command bumpversion patch with a pre-defined .bumpversion.cfg it always shows me the error message below:

.bumpversion.cfg:7: new blank line at EOF.

I had strip the new blank line but bumpversion seems like adding another newline for me automatically. Any thoughts?

Hi!

I'm trying to implement bumpversion in my workflow.
What I want bumped is the version number for a *.deb package. The problem is that deb versioning has the following syntax:

mypackage_0.0.10-storm0_amd64.deb

I have this cfg:

[bumpversion]
current_version = 0.0.10-storm0
serialize = {major}.{minor}.{patch}-storm{package}
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)-storm(?P<package>\d+)
files = Makefile

And my Makefile to be bumped:

...
NAME = mypackage0
VERSION = 0.0.10-storm0
...

If I run the following command the package number (-storm0) part gets removed in both .bumpversion.cfg and Makefile.

bumpversion patch

But command line like this works:

bumpversion --parse '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)-storm(?P<package>\d+)' --serialize '{major}.{minor}.{patch}-storm{package}' patch

Is there something wrong with my config file or is this not possible to do?
Also, is there now or would it in the future be possible to bump the custom package number as well?

Thanks,
-Daniel

According to sections 9 and 10 of semver.org, we could add pre-release tags and meta data.

Basically: major.minor.patch-pre-release-foo+meta.data.goes.here

If you're going to do this, let me know. If not I'll fork and do it.

thanks

A non-ASCII commit message cannot be specified in the config file:

$ cat .bumpversion.cfg

[bumpversion]
message = Bump version: {current_version} → {new_version}
files = setup.py mylib/__init__.py
commit = True
tag = True

$ bumpversion minor

Traceback (most recent call last):
File "/home/petr/dev/virtualenvs/tmxlib/bin/bumpversion", line 8, in <module>
    load_entry_point('bumpversion==0.3.4', 'console_scripts', 'bumpversion')()
File "/home/petr/dev/virtualenvs/tmxlib/lib/python2.7/site-packages/bumpversion/__init__.py", line 347, in main
    config.write(s)
File "/usr/lib64/python2.7/ConfigParser.py", line 412, in write
    key = " = ".join((key, str(value).replace('\n', '\n\t')))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2192' in position 32: ordinal not in range(128)

Jump the bandwagon, it's too convenient not to :).

Coverage, pep8, isort, pytest and other tools do this too.

In trying to employ bumpversion for the comtypes project, I found that on a Windows host, running bumpversion will create a large diff, replacing Unix newlines with Windows newlines.

Bumpversion should retain the newlines of the original file.

I run:

bumpversion --config .bumpversion.cfg --new-version 0.5.2

My config:

[bumpversion]
files = README.rst docs/Makefile docs/make.py hddm/__init__.py
commit = True
tag = True
current_version = 0.5.2.beta

Which gives me the error msg:

 bumpversion: error: argument --new-version: expected one argument

I must be doing something obviously wrong but not sure what?

Oversimplifying, say I have the following ./package.json that only contains 3-part semver version numbers:

{"version" : "1.2.3"}

and a file Contents/Info.plist that includes the complete version string:

        <key>CFBundleVersion</key>
        <string>1.2.3.19-build1234</string>

I want to bump this so package.json contains 1.2.4 and Contents/Info.plist contains 1.2.4-build1239 afterwards.

It should be possible to use different --serialize formats depending on the file. Also other options, if that makes sense.

Hi,

Your soft is great and we use it for our python packages, witch contains files with versions number in it.
But it would be great if "file" could be an option, so we could use your soft with other projects, based only on git tags.

I know that, with this feature, your application would just make a git commit; git tag, but it will still simplify the version number management.

Thanks

Originally reported by @jalanb in #11

$ bumpversion -h | grep part
Traceback (most recent call last):
  File "/Users/jab/bin/bumpversion", line 7, in <module>
    main()
  File "/usr/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 301, in main
    args = parser3.parse_args(remaining_argv)
  File "/usr/local/lib/python2.7/argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/local/lib/python2.7/argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/local/lib/python2.7/argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/local/lib/python2.7/argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "/usr/local/lib/python2.7/argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/local/lib/python2.7/argparse.py", line 993, in __call__
    parser.print_help()
  File "/usr/local/lib/python2.7/argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/local/lib/python2.7/argparse.py", line 2317, in _print_message
    file.write(message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2192' in position 1630: ordinal not in range(128)

Originally reported by @jalanb in #11

$ bumpversion -v
usage: bumpversion [-h] [--config-file FILE] [--parse REGEX] [--serialize FORMAT] [--current-version VERSION] [--dry-run]
                   [--new-version VERSION] [--commit | --no-commit] [--tag | --no-tag] [--tag-name TAG_NAME] [--message COMMIT_MSG]
                   part [file [file ...]]
bumpversion: error: too few arguments

$ bumpversion --version
usage: bumpversion [-h] [--config-file FILE] [--parse REGEX] [--serialize FORMAT] [--current-version VERSION] [--dry-run]
                   [--new-version VERSION] [--commit | --no-commit] [--tag | --no-tag] [--tag-name TAG_NAME] [--message COMMIT_MSG]
                   part [file [file ...]]
bumpversion: error: too few arguments

I think that bumpversion, more than most other commands available to us, should be capable of showing its own version number in response to a (fairly) standard request for it.

(Nor is version number shown in the help text0

Using a .bumpversion.cfg like the below, and doing bumpversion minor

[bumpversion]
commit = True
tag = True
tag_name = "{new_version}"

the tag_name argument as specified in the README.rst has no effect - it goes into parser2 as a default correctly, but somewhere along the lines it gets reset to the global default ("v{new_version}") so that when vcs.tag(args.tag_name.format(**formatargs)) is hit, the wrong string is used. I've tried this with and without quotes, without success.

Using it via the CLI, eg: `bumpversion minor --tag-name="{new_version}" works as I'd expect.

Addendum: the example in the README.rst for using it via the CLI is incorrect -- it's using the message example.

Edited to note: using 0.3.3 from PyPI.

I defined current_versionin bumpversion.cfg file, but after I bumped version, it got removed from the file completely. Shouldn't it be just updated?

Hi,

Firstly, I think bump version is awesome. It solves a lot of problems I have had with versioning in the past. However, there is one capability I wish it had. That is to be able to define the value for the part on the command line, i.e.

$ bumpversion build=$BUILD_NUM

So in this case it would use the provided value rather than increment an existing value.

I ask for this as it would make my workflow much easier. Here's my workflow.

• Once I have finished developing some code I use Bumpversion to increase the value of either the major, minor or patch. If there was a build number previously then it is removed.
• Bumpversion does the git checkin.
• Bamboo sees the newly checked in code. It runs a build job which checks the code out to a local workspace.
• Bumpversion is called by Bamboo with the 'build=$BUILD_NUM' argument.
• If the build succeeds then Bamboo does a Git checkin and deploys the built artefact to Nexus.

I hope this makes sense?

Cheers.

Des

I'm interested in bumping a version for a package that contains a README with both a ##Current Version **M.m.p** and later
has ##Version History ... * M.m.p ...

When I bump the version, I don't want to change the version pertaining to the version history. So that after a bumpversion patch, I would have ##Current Version **M.m.p+1** and ##Version History ... * M.m.p ... would remain unchanged. It seems like I should be able to do this with parse options and file specific configuration, but I'm not having luck. Any suggestions would be great.

Thanks
Matt

Hello

So I'm confused about how to change from 0.1.0 to 0.1.1-dev and from 0.1.1-dev to 0.1.1 with bumpversion? Is this even possible? It seems like this project does that kind of switch.

This is how my config looks like:

current_version = 0.1.1-dev
commit = False
tag = False
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<release>[a-z]+))?
serialize = 
        {major}.{minor}.{patch}-{release}
        {major}.{minor}.{patch}

[bumpversion:file:setup.py]

[bumpversion:part:release]
values = 
        dev

I'd like to bump from 0.1.1-dev to 0.1.1.

Doing bumpversion release gives

Traceback (most recent call last):
  File "/home/slafs/.virtualenvs/bumptest/bin/bumpversion", line 11, in <module>
    sys.exit(main())
  File "/home/slafs/.virtualenvs/bumptest/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 790, in main
    new_version = current_version.bump(positionals[0], vc.order())
  File "/home/slafs/.virtualenvs/bumptest/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 401, in bump
    new_values[label] = self._values[label].bump()
  File "/home/slafs/.virtualenvs/bumptest/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 342, in bump
    return VersionPart(self.config.bump(self.value), self.config)
  File "/home/slafs/.virtualenvs/bumptest/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 301, in bumpdoint
    return self._values[self._values.index(value)+1]
IndexError: list index out of range

but doing bumpversion patch results in a 0.1.2 release.

Is there something that I'm missing?

VERSION: 0.3.0

When I run bumpversion the files are not committed and tagged.
Probably an error occurs in the "git describe"? command context.

$ bumpversion patch
fatal: No names found, cannot describe anything.

[bumpversion]
files = ...
commit = True
tag = True

NOTE:
Files are bumped, but changes are not committed or tagged.
Problem is indenpendent of bump level (occurs also with "minor").

VERSION: 0.2.1

I just tried out bumpversion and it looks interesting (and promising).
But when I tried out a few steps, it removed the "current_version" info from ".bumpversion.cfg" when I bumped a minor version. The other files were OK.

INITIAL:
current_version = "0.0.1"
Everything checked-in in git repository.

SEQUENCE: 0.0.1 -> 0.0.2 -> 0.1.0 -> 1.0.0

bumpversion
bumpversion --bump minor
bumpversion --bump  major --message "xxx: {new_version}"

The second step from "0.0.2 -> 0.1.0" removed the current_version line in the config file.

Follow up from #25 but a seperate issue IMO:

% bumpversion patch --parse '"(?P<major>\d+)", "(?P<minor>\d+)", "(?P<patch>\d+)"' --serialize '"{major}", "{minor}", "{patch}"'
[master 8c774f3] Bump version: "0", "1", "4" → "0", "1", "5"
 2 files changed, 3 insertions(+), 2 deletions(-)
fatal: 'v"0", "1", "5"' is not a valid tag name.
Traceback (most recent call last):
  File "/usr/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.6', 'console_scripts', 'bumpversion-2.7')()
  File "/usr/lib/python2.7/site-packages/bumpversion/__init__.py", line 430, in main
    vcs.tag(args.tag_name.format(**vcs_context))
  File "/usr/lib/python2.7/site-packages/bumpversion/__init__.py", line 103, in tag
    subprocess.check_call(["git", "tag", name])
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '[u'git', u'tag', u'v"0", "1", "5"']' returned non-zero exit status 128

Running in a python 3.3 virtualenv environ, with 0.4.0 installed from pip/pypi. It throws a TypeError if invoked with --help

~/dev$ bumpversion --help
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./bumpversion/__init__.py", line 580, in main
    args = parser3.parse_args(remaining_argv + positionals)
  File "/usr/lib/python3.3/argparse.py", line 1714, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.3/argparse.py", line 1746, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.3/argparse.py", line 1952, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.3/argparse.py", line 1892, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python3.3/argparse.py", line 1820, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.3/argparse.py", line 1024, in __call__
    parser.print_help()
  File "/usr/lib/python3.3/argparse.py", line 2348, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python3.3/argparse.py", line 2354, in _print_message
    file.write(message)
  File "/usr/lib/python3.3/codecs.py", line 356, in write
    self.stream.write(data)
TypeError: must be str, not bytes

Same is true if I clone the repo and invoke directly

~/dev$ git clone -q https://github.com/peritus/bumpversion.git && cd bumpversion
~/dev/bumpversion (master)$ python3 -c 'import bumpversion;bumpversion.main()' --help
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./bumpversion/__init__.py", line 580, in main
    args = parser3.parse_args(remaining_argv + positionals)
  File "/usr/lib/python3.3/argparse.py", line 1714, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.3/argparse.py", line 1746, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.3/argparse.py", line 1952, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.3/argparse.py", line 1892, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python3.3/argparse.py", line 1820, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.3/argparse.py", line 1024, in __call__
    parser.print_help()
  File "/usr/lib/python3.3/argparse.py", line 2348, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python3.3/argparse.py", line 2354, in _print_message
    file.write(message)
  File "/home/alan/env/dev/lib/python3.3/codecs.py", line 356, in write
    self.stream.write(data)
TypeError: must be str, not bytes

While trying to set version for new package, I've set up a bumpversion.cfg as I normally do.

However bumping version fails with quite strange error:

Traceback (most recent call last):
  File "/home/fizyk/.virtualenvs/mirakuru/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.5.0', 'console_scripts', 'bumpversion')()
  File "/home/fizyk/.virtualenvs/mirakuru/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 885, in main
    f.should_contain_version(current_version, context)
  File "/home/fizyk/.virtualenvs/mirakuru/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 211, in should_contain_version
    assert self.contains(version.original), msg
AssertionError: Did not find '0.0.0' or 'unreleased
-------' in file CHANGES.rst

However works perfectly, when I add a current_version into CHANGES.rst, otherwise it's the error above.

Link to commit introducing bumpversion.cfg:
ClearcodeHQ/mirakuru@3145bd5

Our project went from 1.5.6 to 1.5.7. We were using Django>=1.5.6,<1.6 in our setup.py and noticed the Django version had been getting bumped whenever we ran bumpversion.

There might be an obvious solution to this already and we just need to change our workflow to avoid this sort of collision. I expect it will happen in other files such as a requirements.txt that we use in deployment.

It would be great if bumpversion is published under a recognised open source license.
The current state "as-is" would prevent some folks from using it due the the risk of an unknown license.

installed from master.

% bumpversion patch --new-version 0.0.3
Traceback (most recent call last):
  File "/Users/allanb/.virtualenvs/WORK/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.5', 'console_scripts', 'bumpversion')()
  File "build/bdist.macosx-10.8-x86_64/egg/bumpversion/__init__.py", line 376, in main
TypeError: coercing to Unicode: need string or buffer, NoneType found
[1]    69298 exit 1     bumpversion patch --new-version 0.0.3
111

Currently, when something fails in the bump version operation, some files are already changed, others are not. A user needs to rewind/restore parts into old state to get an consistent issue again.

EXAMPLE:
Configfile contains "files" info that points to a non-existing file.
When you try bumpversion you run into this situation. Parts of the files may be already bumped, others are not yet bumped.

# -- FILE: .bumpversion.cfg
[bumpversion]
files = setup.py non-existing.txt xxx/__init__.py
commit = True
tag = True

When trying out bumpversion for the first time, I found the error message to be distinctly unhelpful

$ bumpversion
usage: bumpversion [-h] [--config-file FILE] [--parse REGEX] [--serialize FORMAT] [--current-version VERSION] [--dry-run]
                   [--new-version VERSION] [--commit | --no-commit] [--tag | --no-tag] [--tag-name TAG_NAME] [--message COMMIT_MSG]
                   part [file [file ...]]
bumpversion: error: too few arguments

Which arguments does it want?

Oh, I see, buried in the middle of that verbiage the word "part" is not surrounded by brackets, nor preceded by dashes. Guess it must be looking for a "part" then. So, why didn't it say that, instead of arguments?

Anyway, what's a "part"? Lets try the help

$ bumpversion -h | grep part
Traceback (most recent call last):
  File "/Users/jab/bin/bumpversion", line 7, in <module>
    main()
  File "/usr/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 301, in main
    args = parser3.parse_args(remaining_argv)
  File "/usr/local/lib/python2.7/argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/local/lib/python2.7/argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/local/lib/python2.7/argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/local/lib/python2.7/argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "/usr/local/lib/python2.7/argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/local/lib/python2.7/argparse.py", line 993, in __call__
    parser.print_help()
  File "/usr/local/lib/python2.7/argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/local/lib/python2.7/argparse.py", line 2317, in _print_message
    file.write(message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2192' in position 1630: ordinal not in range(128)

Not very helpful! Guess I'll have to leave out the grep then.

$ bumpversion -h
usage: bumpversion [-h] [--config-file FILE] [--parse REGEX] [--serialize FORMAT] [--current-version VERSION] [--dry-run]
                   [--new-version VERSION] [--commit | --no-commit] [--tag | --no-tag] [--tag-name TAG_NAME] [--message COMMIT_MSG]
                   part [file [file ...]]

Bumps version strings

positional arguments:
  part                  Part of the version to be bumped.
  file                  Files to change (default: [u'docs/conf.py', u'docs/index.rst'])

optional arguments:
  -h, --help            show this help message and exit
  --config-file FILE    Config file to read most of the variables from (default: .bumpversion.cfg)
  --parse REGEX         Regex parsing the version string (default: (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+))
  --serialize FORMAT    How to format what is parsed back to a version (default: {major}.{minor}.{patch})
  --current-version VERSION
                        Version that needs to be updated (default: 0.0.2)
  --dry-run, -n         Don't write any files, just pretend. (default: False)
  --new-version VERSION
                        New version that should be in the files (default: 0.0.2)
  --commit              Commit to version control (default: True)
  --no-commit           Do not commit to version control
  --tag                 Create a tag in version control (default: True)
  --no-tag              Do not create a tag in version control
  --tag-name TAG_NAME   Tag name (only works with --tag) (default: v{new_version})
  --message COMMIT_MSG, -m COMMIT_MSG
                        Commit message (default: Bump version: {current_version} → {new_version})

Even more verbiage, in the middle of which is

  part                  Part of the version to be bumped.

Not exactly the most helpful help ever. In fact, given that the command is called "bumpversion" and the missing argument is called "part" I would opine that "Part of the version to be bumped" actually says nothing at all.

OK, let's try the website, where we find

part

Part of the version to increase.

Valid values include those given in the --serialize / --parse option.

But I didn't use the --serialize / --parse option. And they are "options", so I don't have to use them. What's the default?

Further down on the web page we find
--serialize / serialize =

default: "{major}.{minor}.{patch}"

Not sure what syntax that is - does that mean I have to use 3 parts, or 3 parts to make one part, or that I can change it to use 3 parts, or ..., or what?

All told - that is such an obscure way of saying what the basic way of using the command is as to be grossly unhelpful.

I would suggest that the usage message should mention "parts", not "arguments". And the default allowable arguments of major/minor/patch should be mentioned in the usage message. They should also be, at least, available for reading on the command line, not just on the website.

Finally, and less obviously, I would suggest that part be made optional, and the simplest avaialble command should be

$ bumpversion

which should bump the patch level

Hey,

I'm trying to use new-version to set a custom version but while it's correctly changed in the .bumpversion.cfg, it's not in the file added to the "files" list :

bumpversion patch --allow-dirty --dry-run --verbose --new-version 0.9.3

I can't understand why the part is mandatory when we provide a custom version for the package, but in my case, the part is used to increment the version in the file while the version in .bumpversion.cfg is set to the 0.9.3
I would expect to have versions set to 0.9.3 everywhere

Here is the output of the dry-run :

Reading config file .bumpversion.cfg:
[bumpversion]
current_version = 0.7.2
files = myp/__init__.py
message = v{new_version}
tag_name = {new_version}
tag = true
commit = true

Parsing version '0.7.2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
Parsed the following values: major=0, minor=7, patch=2
Attempting to increment part 'patch'
Values are now: major=0, minor=7, patch=3
Dry run active, won't touch any files.
New version will be '0.9.3'
Asserting files myp/__init__.py contain the version string:
Found '0.7.2' in myp/__init__.py at line 0: __version__ = '0.7.2'
Would change file myp/__init__.py:
--- a/myp/__init__.py
+++ b/myp/__init__.py
@@ -1,4 +1,4 @@
-__version__ = '0.7.2'
+__version__ = '0.7.3'

 try:
     from myp.mapping import Digest
Would write to config file .bumpversion.cfg:
[bumpversion]
current_version = 0.9.3
files = myp/__init__.py
message = v{new_version}
tag_name = {new_version}
tag = true
commit = true

Would prepare Git commit
Would add changes in file 'myp/__init__.py' to Git
Would add changes in file '.bumpversion.cfg' to Git
Would commit to Git with message 'v0.9.3'
Would tag '0.9.3' in Git

The use case is that when going from 1.2.3dev to 1.2.3 it should be tagged but not when advancing further to 1.2.4dev

soo, maybe something like:

tag = True
tag_exlude =
    release:dev

Originally reported by @thomasf in #43:

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

There is now output about what would happen without --dry-run

Signed tag creation could also be supported. An optional cli and config option would be ideal.

When trying to invoke bumpversion using Windows on Python 3, it fails with this traceback:

C:\Users\jaraco\yg\pan [default tip]> bumpversion.pya minor
Traceback (most recent call last):
  File "c:\python\scripts\bumpversion.pya", line 9, in <module>
    load_entry_point('bumpversion==0.3.8', 'console_scripts', 'bumpversion')()
  File "C:\Program Files\Python34\lib\site-packages\bumpversion-0.3.8-py3.4.egg\bumpversion\__init__.py", line 579, in main
  File "C:\Program Files\Python34\lib\site-packages\bumpversion-0.3.8-py3.4.egg\bumpversion\__init__.py", line 163, in commit
  File "C:\Program Files\Python34\lib\subprocess.py", line 605, in check_output
    with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
  File "C:\Program Files\Python34\lib\subprocess.py", line 848, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python34\lib\subprocess.py", line 1078, in _execute_child
    args = list2cmdline(args)
  File "C:\Program Files\Python34\lib\subprocess.py", line 661, in list2cmdline
    needquote = (" " in arg) or ("\t" in arg) or not arg
TypeError: Type str doesn't support the buffer API

This issue is due in part to the encoding of messages as bytes even though subprocess expects them to be strings.

Simply removing the encoding works around the TypeError and the program runs to completion, but the commit message has a "?" character in place of the "→". On further investigation, it appears the honoring of that character may be a bug with mercurial and not bumpversion or subprocess.

I'm able to run this simple script under Python 3 and it outputs the message properly:

# -*- coding: utf-8 -*-

import subprocess

msg = "A \u2192 B"
msg2 = "A → B"
assert msg == msg2
subprocess.call(["Powershell", "-C", "echo '" + msg + "'"])

Furthermore, I've confirmed that if I pass the msg to another Python 3 subprocess, the character in sys.argv is in fact unicode. If I pass the msg to a Python 2 subprocess, the character is lost and replaced by a '?'.

Overall, I believe the proper thing to do is remove the encoding of the string before passing to subprocess.

However, I suspect that will only work on Python 3 due to Python 1759845, so perhaps bumpversion should only do the encoding on Python 2.

I'm trying to use bumpversion on Windows, but I get an error when I try to autocommit with git. I believe the problem is in BaseVCS.commit with the following code:

subprocess.check_output(cls._COMMIT_COMMAND + [f.name], env=dict(
    list(os.environ.items()) + [('HGENCODING', 'utf-8')]
))

Dumping env from within subprocess.py gives the following output:

{

...

 'FRAMEWORKVERSION': 'v4.0.30319',
 'FRAMEWORKVERSION32': 'v4.0.30319',
 'FSHARPINSTALLDIR': 'C:\\Program Files (x86)\\Microsoft SDKs\\F#\\3.1\\Framework\\v4.0\\',
 u'HGENCODING': u'utf-8',
 'HOME': 'C:\\Users\\rgray',
 'HOMEPATH': '\\',

...

}

Note that HGENCODING seems to have been added to the dict as unicode. If I force it to ascii as follows then it works as expected:

subprocess.check_output(cls._COMMIT_COMMAND + [f.name], env=dict(
    list(os.environ.items()) + [('HGENCODING'.encode('ascii'), 'utf-8'.encode('ascii'))]
))

I will submit a pull request with this fix.

The stack trace:

Traceback (most recent call last):
  File "C:\Python27\Scripts\bumpversion-script.py", line 9, in <module>
    load_entry_point('bumpversion==0.5.0', 'console_scripts', 'bumpversion')()
  File "C:\Python27\lib\site-packages\bumpversion\__init__.py", line 965, in main
    vcs.commit(message=commit_message)
  File "C:\Python27\lib\site-packages\bumpversion\__init__.py", line 74, in commit
    list(os.environ.items()) + [('HGENCODING', 'utf-8')]
  File "C:\Python27\lib\subprocess.py", line 537, in check_output
    process = Popen(stdout=PIPE, *popenargs, **kwargs)
  File "C:\Python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
TypeError: environment can only contain strings

Ran into an issue where explicitly having tag / commit = False in .bumpversion.cfg resulted in a git commit and a tag :( Not that I understand how the behavior works I removed them but it might be worth fixing for others.

VERSION: bumpversion 0.3.0

The new version hast the following problem:

$ bumpversion -h
Traceback (most recent call last):
  File "/.../virtualenv/bumpversion.example/bin/bumpversion", line 8, in <module>
    load_entry_point('bumpversion==0.3.0', 'console_scripts', 'bumpversion')()
  File "/.../virtualenv/bumpversion.example/lib/python2.7/site-packages/bumpversion/__init__.py", line 226, in main
    context=dict(list(prefixed_environ().items()) + list(vcs_info.items()))
  File "/.../virtualenv/bumpversion.example/lib/python2.7/site-packages/bumpversion/__init__.py", line 148, in attempt_version_bump
    assert bumped
AssertionError

This problem exists only in a directory under bump version (and git) control.
When I go one directory level up, everything is fine.

BACKGROUND INFO:
I created a virtualenv w/ bumpversion 0.2.1.
There I create a git repository to explore bumpversion.
Now I upgraded the virtualenv to version 0.3.0.

README.rst contains a broken URL in the screencast section:

Screencast
==========

.. image:: https://dl.dropboxusercontent.com/u/8735936/Screen%20Shot%202013-04-12%20at%202.43.46%20PM.png
  :target: http://goo.gl/gljhM

The http://goo.gl/gljhM URL redirects to http://ascii.io/a/3828 but the ascii.io domain expired and the project moved to asciinema.org.
The same old screencast is now available at https://asciinema.org/a/3828

In a lot of projects apart from project's version, there's also a CHANGELOG of some sort.

Changelogs usually contains a bunch of entries for past releases and entry called "current version" or something like that.

It would be useful to be able to bump versions for the changelog as well, but without touching previous entries, that also contain versions.

Additionally, it could be good to add a current date to such entry (like here: https://pypi.python.org/pypi/pyramid/1.4 for pyramid)

Some modules mimic sys.version_info, i.e. like this:

__version_info__ = ("0", "1", "4")
__version__ = ".".join(__version_info__)

In that case, a simple before.replace(... isn't sufficient.

I've got my local machine wheel-enabled, but for some reason bumpversion isn't working for me when installed via wheel.

$ pip install bumpversion
Downloading/unpacking bumpversion
  Downloading bumpversion-0.3.4-py2.py3-none-any.whl
Installing collected packages: bumpversion
Successfully installed bumpversion
Cleaning up...

$ bumpversion
Traceback (most recent call last):
  File "/Users/brandon/.virtualenvs/castaway/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.4', 'console_scripts', 'bumpversion')()
  File "/Users/brandon/.virtualenvs/castaway/lib/python2.7/site-packages/pkg_resources.py", line 378, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/Users/brandon/.virtualenvs/castaway/lib/python2.7/site-packages/pkg_resources.py", line 2566, in load_entry_point
    return ep.load()
  File "/Users/brandon/.virtualenvs/castaway/lib/python2.7/site-packages/pkg_resources.py", line 2260, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named bumpversion

The bumpversion package is not copied into site-packages for some reason. Another project, django-braces is installed the same way, but the braces package is copied into site-packages:

$ ls ~/.virtualenvs/castaway/lib/python2.7/site-packages/
Django.egg-link                    ipython-1.0.0.dist-info
IPython                            model_utils
PIL                                pip
Pillow-2.1.0-py2.7.egg-info        pip-1.4.1-py2.7.egg-info
South-0.8.2.dist-info              pkg_resources.py
_markerlib                         pkg_resources.pyc
braces                             setuptools
bumpversion-0.3.4.dist-info        setuptools-0.9.8.dist-info
django-castaway.egg-link           six-1.3.0.dist-info
django_braces-1.2.2.dist-info      six.py
django_model_utils-1.4.0.dist-info south
easy-install.pth                   usr
easy_install.py                    wheel
ipdb                               wheel-0.21.0.dist-info
ipdb-0.7.dist-info

This is with python 2.7.5, pip 1.4.1 and setuptools 0.9.8.

I tried to debug this for awhile, but couldn't get anywhere. It works fine when I manually download the package and install with python setup.py install.

Some workflows require an intermediate step between changing the version strings in the files and the actual commit or tag. The current state of the implementation is all or nothing.

The workaround executing bumpversion, changing stuff and amend-commit-ing doesn't work because the tagged commit is the original, unamended one and then you'd have to delete that tag and tag the new commit and why are you using this again?

Usecases:

• generating docs
• adding/generating changelogs

Could work something like this:

$> bumpversion --stage-changefiles patch
$> sphinx-build src/ out/
$> git add out/
$> bumpversion --continue

or

$> bumpversion --abort-before=commit patch
Changed files pom.xml, BUILDNUMBER, CHANGELOG.txt
Aborting before commit. After you're done modifying, execute

git commit --file=/tmp/bumpversion_commitmsg23874678236487
git tag v123.4.5 --file=/tmp/bumpversion_tagmsg23874678236487

$> git log > CHANGELOG.txt
$> # ...

or

...

f0baac8 is kind of needed to do semver properly. It would be nice if that was available in a release version

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.