peritus / bumpversion Goto Github PK
View Code? Open in Web Editor NEWVersion-bump your software with a single command
Home Page: https://pypi.python.org/pypi/bumpversion
License: MIT License
Version-bump your software with a single command
Home Page: https://pypi.python.org/pypi/bumpversion
License: MIT License
f0baac8 is kind of needed to do semver properly. It would be nice if that was available in a release version
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?
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)
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)
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
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.
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
$ 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
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
During development it is useful to track release candidate versions. Bump version should support bumping major, minor, patch and release_candidate versions.
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
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'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
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.
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
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.
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
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.
I hope this makes sense?
Cheers.
Des
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.
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
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.
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
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.
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.
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:
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
...
Signed tag creation could also be supported. An optional cli and config option would be ideal.
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
.
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.
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.
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)
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?
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?
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
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
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 @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
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.
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: 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.
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?
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
There is now output about what would happen without --dry-run
Jump the bandwagon, it's too convenient not to :).
Coverage, pep8, isort, pytest and other tools do this too.
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
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 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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.