new-version value is not used for other files than .bumpversion.cfg

[cscetbon]

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

[peritus]

.. that is, if you don't use --dry-run, there is 0.9.3 in the .bumpversion.cfg afterwards and 0.7.2 in in myp/__init__.py ?

Could you try using the new files config syntax introduced in 0.5.0, for your case that would be removing

files = myp/__init__.py

and adding as a separate section

[bumpversion:file:myp/__init__.py]

and see whether the result is different (see README for details) ?

[peritus]

Sounds like a bug in bumpversion to me, even if only when importing pre-0.5 config files.

[cscetbon]

do you still want me to try what you suggested ?

[peritus]

Using the new syntax could be a workaround that might work for you until I have a regression test at hand / released a fix if I can verify the defect.

[cscetbon]

Not better with the new syntax. the part is applied to the file while the new-version value is only applied to .bumpversion.cfg

[cscetbon]

@peritus Can you label this issue as bug ?

[peritus]

Yes it's a bug ;)

[cscetbon]

Thanks

[petebrowne]

Has this been fixed yet? I'm running into this problem with v0.5.1.

[bumpversion]
current_version = 0.8.0

[bumpversion:file:project/__init__.py]

# project/__init__.py
__version__ = "0.8.0"

$ bumpversion patch --allow-dirty --verbose --new-version 0.9.0
# Reading config file .bumpversion.cfg:
# [bumpversion]
# current_version = 0.8.0
# 
# [bumpversion:file:project/__init__.py]
# 
# 
# Parsing version '0.8.0' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
# Parsed the following values: major=0, minor=8, patch=0
# Attempting to increment part 'patch'
# Values are now: major=0, minor=8, patch=1
# New version will be '0.9.0'
# Asserting files project/__init__.py contain the version string:
# Found '0.8.0' in project/__init__.py at line 0: __version__ = "0.8.0"
# Changing file project/__init__.py:
# --- a/project/__init__.py
# +++ b/project/__init__.py
# @@ -1,3 +1,3 @@
# -__version__ = "0.8.0"
# +__version__ = "0.8.1"
# Writing to config file .bumpversion.cfg:
# [bumpversion]
# current_version = 0.9.0
# 
# [bumpversion:file:project/__init__.py]
# 
# 
# Would prepare Git commit
# Would prepare Git commit
# Would add changes in file 'project/__init__.py' to Git
# Would add changes in file '.bumpversion.cfg' to Git
# Would commit to Git with message 'Bump version: 0.8.0 → 0.9.0'
# Would tag 'v0.9.0' in Git

[cscetbon]

@petebrowne the PR is still opened, so I guess it's still pending

[peritus]

This has not been fixed yet, willing to merge patches including tests and docs (ok, well, one regression test exists already).

Sent from my pocket calculator

On 21 Mar 2015, at 20:48, cscetbon [email protected] wrote:

@petebrowne the PR is still opened, so I guess it's still pending

�
Reply to this email directly or view it on GitHub.

[petebrowne]

Awesome! When will this be released to pypi?