c4urself/bump2version

Version-bump your software with a single command

bump2version's Issues

Error trying to bump/tag a version - failed to run git commit -F /var....

Getting this error when trying to run bump2version

Bumping build number
bump2version build
Failed to run ['git', 'commit', '-F', '/var/folders/xl/brwlvdg11237knt3vyb37v1m0000gn/T/tmpqieqchcy']: return code 1, output: b"On branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n"

Turned out that my bump config was not triggering any changes to the files that needed version updates. Not sure why yet, but triggering a bump2version patch worked fine as it actually updated the file version numbers so there was something to commit. It took me a while to understand why the error occurred so I'm putting this here for future reference.

Starting a part at 0

I have a parse string of

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

that serializes as

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

The build part is defined as

[bumpversion:part:build]
first_value = 0

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

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

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

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

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

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

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

multiple file arguments on the command line, and the file= parameter in [bumpversion]

I have file handling on my mind (#64) and I notice that there is a PendingDeprecationWarning on the ability to provide multiple files on the command line (and a similar warning on the undocumented files = parameter in the main [bumpversion] section of the config file--which accomplishes the same thing).

These PendingDeprecationWarnings are present in the upstream https://github.com/peritus/bumpversion. Why would that functionality be deprecated and is that still the plan?

Failed test `test_subjunctive_dry_run_logging`

My first experience working with GitHub, tox, docker.

I've cloned 0.5.7 version of bump2version and run make test. As I know in committed code usually all the tests must be passed. But my testing summary is:

 __________________________________________________________ summary __________________________________________________________
ERROR:   py27: commands failed
ERROR:   py33: commands failed
ERROR:   py34: commands failed
ERROR:   py35: commands failed
ERROR:   py27-configparser: commands failed
ERROR:   pypy: commands failed
Makefile:3: recipe for target 'test' failed
make: *** [test] Error 1

4 failed, 132 passed in N seconds 

It is known bump2version issue or am I doing something wrong?

One of failed tests example

________________________________ test_log_commitmessage_if_no_commit_tag_but_usable_vcs[git] ________________________________

tmpdir = local('/tmp/pytest-of-root/pytest-5/test_log_commitmessage_if_no_c0'), vcs = 'git'

    @pytest.mark.parametrize(("vcs"), [xfail_if_no_git("git"), xfail_if_no_hg("hg")])
    def test_log_commitmessage_if_no_commit_tag_but_usable_vcs(tmpdir, vcs):
        tmpdir.join("please_touch_me.txt").write("0.3.3")
        tmpdir.chdir()
    
        tmpdir.join(".bumpversion.cfg").write(dedent("""
            [bumpversion]
            files = please_touch_me.txt
            current_version = 0.3.3
            commit = False
            tag = False
            """).strip())
    
        check_call([vcs, "init"])
        check_call([vcs, "add", "please_touch_me.txt"])
        check_call([vcs, "commit", "-m", "initial commit"])
    
        with mock.patch("bumpversion.logger") as logger:
            main(['patch'])
    
        # beware of the trailing space (" ") after "serialize =":
        EXPECTED_LOG = dedent("""
            info|Reading config file .bumpversion.cfg:|
            info|[bumpversion]
            files = please_touch_me.txt
            current_version = 0.3.3
            commit = False
            tag = False|
            info|Parsing version '0.3.3' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'|
            info|Parsed the following values: major=0, minor=3, patch=3|
            info|Attempting to increment part 'patch'|
            info|Values are now: major=0, minor=3, patch=4|
            info|Parsing version '0.3.4' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'|
            info|Parsed the following values: major=0, minor=3, patch=4|
            info|New version will be '0.3.4'|
            info|Asserting files please_touch_me.txt contain the version string:|
            info|Found '0.3.3' in please_touch_me.txt at line 0: 0.3.3|
            info|Changing file please_touch_me.txt:|
            info|--- a/please_touch_me.txt
            +++ b/please_touch_me.txt
            @@ -1 +1 @@
            -0.3.3
            +0.3.4|
            info|Writing to config file .bumpversion.cfg:|
            info|[bumpversion]
            files = please_touch_me.txt
            current_version = 0.3.4
            commit = False
            tag = False
    
            |
            info|Would prepare Git commit|
            info|Would add changes in file 'please_touch_me.txt' to Git|
            info|Would add changes in file '.bumpversion.cfg' to Git|
            info|Would commit to Git with message 'Bump version: 0.3.3 \u2192 0.3.4'|
            info|Would tag 'v0.3.4' with message 'Bump version: 0.3.3 \u2192 0.3.4' in Git|
            """).strip()
    
        if vcs == "hg":
            EXPECTED_LOG = EXPECTED_LOG.replace("Git", "Mercurial")
    
        actual_log ="\n".join(_mock_calls_to_string(logger)[4:])
    
>       assert actual_log == EXPECTED_LOG
E       assert 'info|Reading... not signing|' == "info|Reading ....3.4' in Git|"
E         Skipping 1259 identical leading characters in diff, use -v to show
E         - .4' in Git and not signing|
E         + .4' in Git|

/code/tests/test_cli.py:1241: AssertionError

Quotation marks matter

I had version="0.2.0" in my setup.py but when updating using bump2version patch it made version="version='0.2.0'"
Changing it to version='0.2.0' did solve the problem for now

Rename package too?

Would be nice to also rename package so you can have bumversion and bump2version installed side-by-side.

bumpversion command adds a newline in bumpversion.cfg

I am using pre-commit and one of the hooks I use is is end-of-line-fixer:

end-of-file-fixer - Makes sure files end in a newline and only a newline.

This seems to be causing issues to bump2version. More specifically, bump2version seems to be adding an extra empty line at the end of .bumpversion.cfg which make the hook to fail. As a result, the commit is being aborted.

Is that extra line necessary?

How to keep the metadata part when bumping version?

Hello,

I have reported already the same question on the original project but then found this one which seems to be actively maintained.

We are using semantic versioning (semver.org) in our projects and stumbled upon the following problem:

We have some projects that extend some other upstream projects with some functionality (eg. forks). We want to version our projects with the following semver schema:

1.2.3+4.2.1
1.2.3-SNAPSHOT+4.2.1

where 1.2.3 is our own version of the project and 4.2.1, the metadata part of semver, which reflects the upstream version our changes are based on.

When releasing our versions we would like to have the following flow:

# current_version=1.2.3-SNAPSHOT+4.2.1
$ bumpversion release
# current_version=1.2.3+4.2.1
$ bumpversion patch
# current_version=1.2.4-SNAPSHOT+4.2.1

Right now we use the following configuration:

parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<release>[a-zA-Z]+))?
serialize =
  {major}.{minor}.{patch}-{release}
  {major}.{minor}.{patch}

[bumpversion:part:release]
optional_value = rel
values =
  dev
  rel

Is it possible to implement this kind of workflow where the metadata part (eg. +4.2.1) won't be touched?
I have tried various things but did not come up with something that just leaves the metadata part.
Also it would be great to have one config that covers the case with +metadata and without it.

Thanks a lot.

Discussion: PyPI name transfer

Hi @c4urself, and other maintainers!

Just perusing the PEPs today, and thought about this project while reading PEP-0541 (especially the section on continued maintenance of an abandoned project).

And hey, it's been years since @peritus updated the original project, and I'm assuming they've been completely unreachable ever since, have you considered attempting to get the PyPI maintainers to transfer the project to you?

After all, the original PyPI package still has at least 10 times as many downloads monthly (and at least 2 times when excluding Python 2 users) (according to pypistats.org), so getting the PyPI project would also mean that the people currently using it could receive improvements/patches.

Just some food for thought, and in general, thanks for maintaining the fork! 👍

Add support for premajor, preminor, prepatch, etc.

This is inspired by npm's semver increments. To quote the node docs:

premajor in one call will bump the version up to the next major version and down to a prerelease of that major version. preminor, and prepatch work the same way.

E.g.:

$ version
0.3.5
$ bumpversion patch
Bumped from 0.3.5 to 0.3.6
$ bumpversion preminor
Bumped from 0.3.6 to 0.4.0-dev.0

From what I understand it's not possible to replicate this with bumpversion without using --new-version at some point. Either you always walk through the pre-release steps or you don't walk through them at all.

For instance, this config:

[bumpversion]
current_version = 0.3.5
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<release>[a-z]+))?(\.(?P<build>\d+))?
serialize = 
    {major}.{minor}.{patch}-{release}.{build}
    {major}.{minor}.{patch}

[bumpversion:part:release]
optional_value = gamma
values = 
    dev
    alpha
    beta
    gamma

would behave as follows:

$ version
0.3.5
$ bumpversion patch
Bumped from 0.3.5 to 0.3.6-dev.0
$ bumpversion minor
Bumped from 0.3.6-dev.0 to 0.4.0-dev.0

In many scenarios this is not desirable, as you would want to be able to push out a patch without having to walk through the pre-release steps (e.g. dev → alpha →...).

The only other option is to add first_value = gamma under [bumpversion:part:release] which would change the behavior as follows:

$ version
0.3.5
$ bumpversion patch
Bumped from 0.3.5 to 0.3.6
$ bumpversion minor
Bumped from 0.3.6 to 0.4.0

But to switch to a pre-release you would then have to use --new-version:

$ bumpversion part --new-version=0.4.0-dev.0
Bumped from 0.3.6 to 0.4.0-dev.0

It would be nice to have a shorthand for this rather than having to manually type the release.

P.S.: Thanks for all your work on bump2version! It's nice to see this project alive and thriving.

--new-version: 4.0.1.dev2 becomes 4.0 instead of 4.0.1

I am currently at version 4.0.1.dev2, and want to proceed to non-dev 4.0.1. Instead I end up with 4.0.

Reproduction

The command is $ bump2version dev --new-version 4.0.1,
the code is luckydonald/pytgbot@85bf22.

Other issues

This might probably be related to #30, and could benefit from #22.

Details

Here is the full output, fully how it at some point just changes the version number to be wrong.

$ bump2version --verbose --dry-run --new-version 4.0.1 dev
Reading config file .bumpversion.cfg:
[bumpversion]
current_version = 4.0.1.dev2
commit = True
tag = True
parse = (?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?
serialize = 
        {major}.{minor}.{patch}.{pre}.dev{dev}
        {major}.{minor}.{patch}.dev{dev}
        {major}.{minor}.{patch}
        {major}.{minor}

[bumpversion:part:pre]
optional_value = final
first_value = final
values = 
        a
        b
        rc
        final
        post

[bumpversion:file:pytgbot/__init__.py]

[bumpversion:file:setup.py]

[bumpversion:file:README.md]


Parsing version '4.0.1.dev2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?'
Parsed the following values: dev=2, major=4, minor=0, patch=1, pre=final
Attempting to increment part 'dev'
Values are now: dev=3, major=4, minor=0, patch=1, pre=0
Dry run active, won't touch any files.
Parsing version '4.0.1' using regexp '(?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?'
Parsed the following values: dev=0, major=4, minor=0, patch=0, pre=final
New version will be '4.0.1'
Asserting files pytgbot/__init__.py, setup.py, README.md contain the version string:
Found '4.0.1.dev2' in pytgbot/__init__.py at line 5: __version__ = "4.0.1.dev2"
Found '4.0.1.dev2' in setup.py at line 10:     name='pytgbot', version="4.0.1.dev2",
Found '4.0.1.dev2' in README.md at line 1: ### Version [4.0.1.dev2 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
Would change file pytgbot/__init__.py:
--- a/pytgbot/__init__.py
+++ b/pytgbot/__init__.py
@@ -3,7 +3,7 @@
 from .bot import Bot
 
 __author__ = 'luckydonald'
-__version__ = "4.0.1.dev2"
+__version__ = "4.0"
 __all__ = ["api_types", "bot", "Bot"]
 VERSION = __version__
 
Would change file setup.py:
--- a/setup.py
+++ b/setup.py
@@ -8,7 +8,7 @@
 long_description = """A Python module that connects to the Telegram bot api, allowing to interact with Telegram users or groups."""
 
 setup(
-    name='pytgbot', version="4.0.1.dev2",
+    name='pytgbot', version="4.0",
     description='Connect to the Telegram Bot API, receive and send Telegram messages.',
     long_description=long_description,
     # The project's main homepage.
Would change file README.md:
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # pytgbot - Telegram Bot API [`4`.`0`](https://core.telegram.org/bots/api)
-### Version [4.0.1.dev2 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
+### Version [4.0 (stable)](https://github.com/luckydonald/pytgbot/blob/master/CHANGELOG.md#changelog) [![Join pytgbot group on telegram](https://img.shields.io/badge/Telegram%20Group-Join-blue.svg)](https://telegram.me/pytg_group)
 ###### Python module to access the telegram bot api.
 
 Native python package with a pure Python interface for the [Telegram Bot API](https://core.telegram.org/bots).
Would write to config file .bumpversion.cfg:
[bumpversion]
current_version = 4.0.1
commit = True
tag = True
parse = (?P<major>\d+)\.(?P<minor>\d+)(\.(?P<patch>\d+)(\.(?P<pre>a|b|rc|final|post)?((dev)?(?P<dev>\d+))?))?
serialize = 
        {major}.{minor}.{patch}.{pre}.dev{dev}
        {major}.{minor}.{patch}.dev{dev}
        {major}.{minor}.{patch}
        {major}.{minor}

[bumpversion:part:pre]
optional_value = final
first_value = final
values = 
        a
        b
        rc
        final
        post

[bumpversion:file:pytgbot/__init__.py]

[bumpversion:file:setup.py]

[bumpversion:file:README.md]


Would prepare Git commit
Would add changes in file 'pytgbot/__init__.py' to Git
Would add changes in file 'setup.py' to Git
Would add changes in file 'README.md' to Git
Would add changes in file '.bumpversion.cfg' to Git
Would commit to Git with message 'Bump version: 4.0.1.dev2 → 4.0.1'
Would tag 'v4.0.1' with message 'Bump version: 4.0.1.dev2 → 4.0.1' in Git and not signing

Can you append timestamp to a version?

I don't want 2 developers to clobber eachothers artifacts, so it would be helpful if we could version a dev build as "app-name-1.0.2-20190924151024-py2.py3-none-any.whl". Our wheels are created in Jenkins, and then we use twine to put them in Artifactory, so simply incrementing a build number or something similar is a bad idea, as then our devs would have to "git fetch" after every push to a dev branch.

New option to push tag?

Hello,
thank you for this nice and handy tool.
As of now it works really nice, but one thing I think would somewhat be nice is an option to automatically push a tag after it was created.

This options only would make sense when a user creates a tag and under git would create the question to which remote the tag should be pushed to (e.g. is it origin or upstream?).

I guess I'm wondering if anyone (or you as creator of the library) would be interested in such a feature.

Theoretically this could also be achieved by #57

Config works in `.bumpversion.cfg` but not in `setup.cfg`

Hi, I have a bit of a complex search/replace string for my CHANGELOG and was hoping to unify my configs by moving everything into setup.cfg and pyproject.toml (only would of those would be preferable, but I digress). However, when I move my bumpversion config into setup.cfg I keep getting some errors due to the way the search and replace get parsed out. Here's the relevant section, I imagine I just need to change the formatting but I've tried a bunch of stuff with no success. Any help would be greatly appreciated!

[bumpversion:file:CHANGELOG.rst]
search = [Unreleased]
	------------
replace = [Unreleased]
	------------
	[{new_version}] - {now:%Y-%m-%d}
	-----------------------------

It is possible to get version-release from multiple lines (rpm spec)?

I want to also bump release number of spec file, but it was on separate line. e.g.

Version: 0.5.0
Release: 1{?%dist}

My .bumpversion.cfg

[bumpversion]
current_version = 0.5.0
commit = True
tag = True

[bumpversion:file:mysrv/__init__.py]

[bumpversion:file:spec/mysrv.spec]

Get rid of the `list` logger and just use sys.stdout

This may be a bit controversial, but we have exactly one log call for the list logger and it's just outputting the message sent. Why not just use sys.stdout.write or similar for that one call? Reasoning: this would clean up some code and make it quite a bit easier to read and make it easier to test logging code.

README on pypi.org not readable

https://pypi.org/project/bump2version/ shows content of README, which is broken.

there seem to be two reasons:

• the value for long_description is provided as bytes and not as a string
• the content if formatted as markdown and not reStructuredText

With refactored https://pypi.org well readable README can serve as great presentation of the package and bump2version can definitely do better.

If reStructuredText seems too difficult, I volunteer to write it properly. It is not so difficult and such great tool as bump2version deserves good presentation.

Add --dry-run option

Dry-run mode is useful:

• for development and debugging .bumpversion.cfg
• for continuous integration in tox.ini file: implemented as tox environment it could check that files specified in cfg file are parsed and could be replaced with version correctly.

Dry-run should not modify any files.

globbing in config file parsing, like [bumpversion:file:*.py]

There was a similar Issue open on the original bumpversion: peritus/bumpversion#104

but it was opened about a month before the last commit on that project.

Perhaps more succinctly composed: the issue is, in addition to having the string after the final : in [bumpversion:file:file_path] be interpreted as a strict path, could it be run through the glob library or the .glob() function of pathlib's Path object? So that the rules in such a section could be applied to multiple files that match the pattern?

Clearly, that's possible, but is there any reason not to implement it?

adding custom application tag with version in the part

The part works fine for the values provided in it but I would like to provide a custom value for the releases like application name while working on the branch. Because my repository has templates for multiple applications and I would like to use versioning with that application name while making changes for that particular application.

Example:
Say, master branch has version 0.0.1 and I am on a branch taken from the master making changes to an application rabbitmq templates. So while doing a version on that branch, I would like it to be 0.0.1-rabbitmq00.

And while merging back to master, I want to bump up the version on the master from 0.0.1 to 0.0.2` and lose whatever application name and its counter I have on the branch.

How do I do it? I cannot use part here the way I want as it increments the part from one application to another if I list those application names as custom values.

[bumpversion]
current_version = 0.0.0
commit = True
tag = True
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<application>[a-z]+)(?P<rc>\d+))?
serialize =
	{major}.{minor}.{patch}-{application}{rc}
	{major}.{minor}.{patch}

[bumpversion:part:application]
optional_value = devops
values =
	rabbitmq
	lambda
        codedeploy
	devops

[bumpversion:part:rc]

[bumpversion:file:METADATA]

strict search

Current behavior:

config:

[bumpversion:file:CHANGES.md]
search = Version Future
replace = Version {new_version}

Assume this CHANGES.md:

Version 0.0.1
--------------

bump2version patch Result:

Version Version 0.0.2
--------------

Expected result:

Version 0.0.1
--------------

Moving from developing on MAC to Windows and hitting command:warning: LF will be replaced by CRLF in src/setup.cfg.

Throws this error.

Any ideas how to overcome?

2018-08-31 14:41:59,609 StackRunner     - ERROR exec_in_sub                              - ERROR from command:warning: LF will be replaced by CRLF in src/setup.cfg.
The file will have its original line endings in your working directory.
Traceback (most recent call last):
  File "c:\python27amd64\lib\runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python27amd64\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Python27amd64\Scripts\bump2version.exe\__main__.py", line 9, in <module>
  File "c:\python27amd64\lib\site-packages\bumpversion\__init__.py", line 938, in main
    vcs.commit(message=commit_message)
  File "c:\python27amd64\lib\site-packages\bumpversion\__init__.py", line 71, in commit
    f = NamedTemporaryFile('wb', delete=False)
  File "c:\python27amd64\lib\tempfile.py", line 475, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "c:\python27amd64\lib\tempfile.py", line 245, in _mkstemp_inner
    _set_cloexec(fd)
  File "c:\python27amd64\lib\tempfile.py", line 50, in _set_cloexec
    flags = _fcntl.fcntl(fd, _fcntl.F_GETFD, 0)
AttributeError: 'module' object has no attribute 'F_GETFD'

Move to testfixtures' LogCapture for checking all log-based tests?

Uploading an sdist

Hi, would you mind uploading an sdist to PyPI in addition to the wheel? That should be

python setup.py sdist
twine upload

Thank you.

Screencast link in README is dead.

The screencast link in README.md is dead

https://asciinema.org/a/3828

`part` should not be required if supplying `--new-version`

This one is pretty basic, but I must be missing something in how people are using this.

Part shouldn't be a required field if you're supplying --new-version. It doesn't make any sense.

If I'm at 0.1.0, and I want to go to 0.1.1, I should be able to do: bumpversion --new-version 0.1.1. I know I can just do bumpversion minor but in this scenario the version is being driven by CI so it may not be sequential.

Anyways, seems like a bug. But this project is old enough that I probably just took some crazy pills. :)

You be the judge!

Expose parts (major/minor/patch/...) in 'replace' too

Hi,

I've been surprised a couple of times that I can use {major}, {minor} and {patch} placeholders in serialize, but not in replace. In replace, only new_version is available, which is already formatted by the serialize format.

Is this a design choice or would you be open to change that?

I would definitely like to have to flexibility to choose between new_version and major/minor/patch.

A bit too aggro on the version parsing

Hey there, love the work you're doing to keep this alive

I've noticed, in my adventures setting up PEX builds for python apps, that any edition of bumpversion (bump2version, advbumpversion, etc) will aggressively match versions from setup.cfg in the listed files. In our case, setup.py is one of those files (normal stuff) and our install_requires can regularly list exact versions of other apps (abnormal but supported). Bumpversion likes to Loki it up in there.

Let's say my setup.cfg looks like this, a real basic one:

>> cat setup.cfg 
[bumpversion]
current_version = 1.0.2
commit = False
tag = False
tag_name = {new_version}

[bumpversion:file:setup.py]

[bumpversion:file:myapp/__init__.py]

And my setup.py looks like this:

from setuptools import setup
__version__ = '1.0.2'

setup(
    name='myapp',
    version=__version__,
    install_requires=[
        'Flask==1.0.2'
    ]
    ...other useful irrelevant stuff....
)

If I run bumpversion on this project, it bumps the Flask version as well since it's the same "version", and causes our CICD to burst into flames.

What would it take to get a config/cli option for "keyword"? Like in setup.cfg, we can say what pattern our version follows, so it would be equally awesome to list a keyword that will always be found on the lines with the version, such as "version", so bumpversion only replaces versions found on lines that contain the keyword.

Cannot make it work properly

Hi there,

I am trying to make it work to fit our needs but obviously I must be doing something wrong.

The idea of our versioning is the next:

Major.Minor.Patch-Prepatch == 1.1.0-0

How do I have to configure the bumpversion.cfg to make it work?
Currently my config is the following:

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

[bumpversion:file:setup.py]

But when I do the following command:

bump2version --config-file bumpversion.cfg --current-version $(python setup.py --version) release setup.py --allow-dirty

I get this version on my setup.py:

'version': '3.1.0-1-1'

Could someone please explain what am I doing wrong? Or what is missing?

Thank you!

Fix deprecation errors on pytest v4.0.x

PyTest version 4.0.0 is released and this is breaking both Travis and AppVeyor on deprecation errors.

I stumbled into this in #41.

The main issue seems to be this one: https://docs.pytest.org/en/latest/deprecations.html#marks-in-pytest-mark-parametrize .

You can turn these errors into warnings through a pytest.ini file (see 29b6f90) , but that's only temporary since 4.1.x will break hard on these deprecations.

So we need to port to pytest 4.x. Another option is to pin the pytest version to <4.0.0.

Interpolation should happen within the logging handler

Right now the code is littered with: logger.info('foo {}'.format('bar')) style calls, it would be better if we let the logger handle the interpolation: logger.info('foo %s', bar)

Don't replace version numbers of *partial* matches

Given a setup.py file containing those two lines:

if pkg_resources.get_distribution("setuptools").version < "40.1.1":

# ... other lines

    version="0.1.1",

If you bump the version (the patch for example), it will modify 40.1.1 to 40.1.2. This is because it's a simple replace using the current version. It probably should use a regex to find the version the file. The only work around I found was to the change the search to include the double quotes.

Add support for metadata.version as canonical version

Currently, bump2version allows the current_version to be specified in setup.cfg. Setuptools also through declarative config allows versions to be defined in setup.cfg. However, if you try to define the bump2version and package version in the same setup.cfg file, bump2version can't bump it. Consider this setup.cfg:

[bumpversion]
current_version = 2.0.0

[metadata]
version = 2.0.0

[bumpversion:file:setup.cfg]

Although this config follows the patterns of other configs, bump2version will only bump the bumpversion.current_version

I suspect this can be addressed by using a separate .bumpversion.cfg file so that it can bump the version in setup.cfg, but that feels unnecessarily messy.

I propose instead bump2version should honor (either as opt-in or by default) the metadata.version as the "current version".

bumpversion and setuptools have differing interpolation behavior

(Migrating from peritus/bumpversion#181)

The interpolation behavior of config files by bumpversion and setuptools is not the same. bumpversion uses no interpolation (e.g. configparser.RawConfigParser), but setuptools uses the default interpolation of configparser.ConfigParser, which is "basic interpolation".

In general, this should not be an issue, but because bumpversion supports setting configuration in the setup.cfg file, options that might be interpolated by the parser would not cause an issue if they appear in the .bumpversion.cfg, but suddenly break the install/build process if they are moved to the setup.cfg.

For example, I had the following in my .bumpversion.cfg to automatically insert the date in my CHANGELOG along with the version.

[bumpversion:file:docs/source/changelog.rst]
search = XX-XX-XXXX v. X.X.X
replace = {now:%m-%d-%Y} v. {new_version}

When I moved this into my setup.cfg, bumpversion still works but the following happens when I try to run anything with setup.py.

Traceback (most recent call last):
 ...
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%m-%d-%Y} v. {new_version}'

The obvious solution of escaping the % so that they are not interpolated (e.g. {now:%%m-%%d-%%Y} causes setuptools to not fail, but then bumpversion inserts the literal string "%%m-%%d-%%Y" instead of formatting the date because the percent signs are not treated as needing escaping.

It turns out that other packages have run into this, like pytest: pytest-dev/pytest#3062. This distutils mailing thread also illustrates that the python devs are struggling with if this was a good design decision, but that's a whole other can of worms.

My proposal: When loading from setup.cfg, use configparser.ConfigParser, and when loading from .bumpversion.cfg, use configparser.RawConfigParser.

enhancement: pre-release support

A release workflow we follow is:

• from 2.4.3 we may create any of the following pre-releases: 2.4.4-rc1, 2.5.0-rc1, 3.0.0-rc1
• from a prerelease we either increment the last digit for a new prerelease, or drop the -rc? for the release

A similar workflow would use -alpha, -beta, -gamma as the pre-release identifiers.

This is only currently supported by bump2version using the --new-version flag, but could be supported by --prerelease and --release flags. (I know, please submit a PR ... :))

New lines in parse

Hello, I'm trying to do a parse/serialize using the following format:

MAJOR=1
MINOR=2
PATCH=3

My bumpversion looks like

[bumpversion]
current_version = 1.2.3

[bumpversion:file:version_info]
parse = "MAJOR=(?P<major>\d+)\nMINOR=(?P<minor>\d+)\nPATCH=(?P<patch>\d+)\n"
serialize = "MAJOR={major}\nMINOR={minor}\nPATCH={patch}\n"

I am getting an assertion error along the lines of:
`AssertionError: Did not find '1.2.3' or 'MAJOR=1\nMINOR=2\nPATCH=3\n' in file version_info

Not incrementing version on all lines inside setup.cfg

Having a setup.cfg with:

[metadata]
version = 0.1.0

[bumpversion]
current_version = 0.1.0

[bumpversion:file:setup.cfg]

With the command bump2version minor the result is:

[bumpversion]
current_version = 0.2.0

[metadata]
version = 0.1.0

[bumpversion:file:setup.cfg]

As you can see only current_version is updated, and the section [bumpversion] it's moved to te top of the file (this doesn't bother me too much)

bump2version version is 0.5.11

Thank you

bump2version deletes comments/commented out lines when using setup.cfg

if using setup.cfg and setting up the version configuration, once I use bump2version part the version gets updated but all the comments are removed.

Is this the expected behaviour?

`TypeError: environment can only contain strings` on Windows 10

I got an error working on Windows 10 with python 3.6.3, bump2version v0.5.7.

The traceback message is:

Traceback (most recent call last):
  File "c:\program files (x86)\python36-32\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\program files (x86)\python36-32\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Program Files (x86)\Python36-32\Scripts\bump2version.exe\__main__.py", line 9, in <module>
  File "c:\program files (x86)\python36-32\lib\site-packages\bumpversion\__init__.py", line 938, in main
    vcs.commit(message=commit_message)
  File "c:\program files (x86)\python36-32\lib\site-packages\bumpversion\__init__.py", line 75, in commit
    list(os.environ.items()) + [(b'HGENCODING', b'utf-8')]
  File "c:\program files (x86)\python36-32\lib\subprocess.py", line 336, in check_output
    **kwargs).stdout
  File "c:\program files (x86)\python36-32\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
  File "c:\program files (x86)\python36-32\lib\subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "c:\program files (x86)\python36-32\lib\subprocess.py", line 997, in _execute_child
    startupinfo)
TypeError: environment can only contain strings

Actually, I solved the issue changing the class BaseVCS in __init__.py as follows:

class BaseVCS(object):

    @classmethod
    def commit(cls, message):
        f = NamedTemporaryFile('wb', delete=False)
        f.write(message.encode('utf-8'))
        f.close()
        subprocess.check_output(cls._COMMIT_COMMAND + [f.name], env=dict(
            [i for i in os.environ.items()] + [(u'HGENCODING', u'utf-8')]
        ))
        os.unlink(f.name)

    @classmethod
    def is_usable(cls):
        try:
            return subprocess.call(
                cls._TEST_USABLE_COMMAND,
                stderr=subprocess.PIPE,
                stdout=subprocess.PIPE
            ) == 0
        except OSError as e:
            if e.errno == 2:
                # mercurial is not installed then, ok.
                return False
            raise

As you can see, I only changed the params for subprocess.check_output:

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

Version interpolation does not act as expected when using format modifiers

I have a project that is using yy.mm for version numbers; and I would like the version to always have a leading zero in the month field. I had initially tried to do this using the following fragment; with no success:

serialize =
	{major}.{minor:02}.{patch}
	{major}.{minor:02}

On closer inspection it appears as though none of the string or integer formatting options work, I've also tried {minor!s:0>2}(produces 19.<bumpversion.VersionPart:NumericVersionPartConfiguration:4>, and {minor:0>2}(produces 19.4) to no avail.

Add --show option to print only the version number

External tools currently have to use grep and sed to extract the version number from the output of bump2version --list.

bump2version --dry-run --list patch | grep current_version | sed -r s,"^.*=",,

This is long and not very readable. Worse yet, Windows doesn't offer grep or sed unless you install Cygwin/GnuWin32/Linux subsystem for Windows[/...] .

Because it's a common need, I'd like to see (and can contribute) this instead:

# print current version
>>> bump2version --show
2.11.3
# print current version with modified serialization
>>> bump2version --show --serialize "Release {major}.{minor} patchlevel {patch}."
Release 2.11 patchlevel 3.
# print 'next' (bumped) version
>>> bump2version patch --show
2.11.4

I would propose that show enforces dry-run behavior so it never touches physical files. If you want to physically bump the version and also show it, you simply have to call bump2version two times.

Handling custom tag messages with Git

There's currently no support for creating annotated tags in Git without specifying the message. The git tag -a option will create an annotated tag and open the editor to write the tag message. This is useful when you may want to include a multiline message such as a change log. To do this currently, I have to use bumpversion and then overwrite the tag manually with Git.

I see it as an annotate_tags option that would be ignored for Mercurial repos, and override the default tag message, calling git tag -a instead of git tag -m. I'm happy to work on implementing this, but I wanted to check here first to make sure that it would be acceptable.

Can I use a tuple as version format, but still use a completely different format for tags?

Hi,

My version format looks like

# tuple that is easy to compare
__version_info__ = (1, 4, 2)
# string version derived from tuple, as the standard __version__ attribute
__version__ = '.'.join(map(str, __version_info__))

Parsing and serialization of the tuple works fine, but the tag name for Git becomes 'v(1, 4, 2)' while of course I'd want 'v1.4.2'.

My first reaction was to set tag_name to 'v{major}.{minor}.{patch}', but the parts (major/minor/patch) can not be used in tag_name. Is this on purpose?

What are my options if I want to have a different serialization in my files versus in the tag name?

I do have a branch which allows tag_name = v{major}.{minor}.{patch} -- let me know if that would fit as a merge request.
https://github.com/florisla/bump2version/tree/all-parts-in-strings

Allow ignoring certain matches

It would be great if there was an option to exclude certain matches from bumping (e.g. by adding a ignore_regex or similar option).

The issue came up in a small project that has all its documentation inside a readme file, including multiple mentions of the current version as well as a changelog. The problem I'm running into is that bump(2)version also bumps the versions in the changelog section.

Use black to start linting/styling the codebase

See: https://github.com/ambv/black

Feature request: tag on specific values of parts

I'd like to see an option to tag the commit when a part of the version reaches a certain value - for example, say I have a release part, which has two possible values, dev and prod. It would be great if the commit was automatically tagged when release reaches prod.

pyproject.toml (PEP 518) support

Hi, I was wondering if there were plans for pyproject.toml support.

see: peritus/bumpversion#192, PEP 518

Tags cannot be Signed

There is currently no option available to sign tags.

I am adding this functionality now and will add a PR shortly.

minor bug --new-version = old-version

If you use the --new-version flag with the current version as an argument, bumpversion corrupts the files :(. I ended up with:

version = version = version = 0.2.0

Handling version repetitions in a single file

So a question for @c4urself I guess ...

There's one design issue in bumpversion that really grinds my gears: it cannot deal with files that have the version multiple times in them. Consider this README.rst:

.. |commits-since| image:: https://img.shields.io/github/commits-since/ionelmc/python-nameless/v0.1.0.svg
    :alt: Commits since latest release
    :target: https://github.com/ionelmc/python-nameless/compare/v0.1.0...master

To be really sure no other content is changed I would need to have something like:

[bumpversion:file:README.rst]
search =
    commits-since/ionelmc/python-nameless/v{current_version}.svg
    compare/v{current_version}...master

Obviously this doesn't work, bumpversion will try to replace \ncommits-since/ionelmc/python-nameless/v{current_version}.svg\ncompare/v{current_version}...master. To make it worse, it won't report any error.

So my question, are you interested in figuring out a better configuration format or I'm barking at the wrong tree (I should make my own fork or whatever)?