c4urself / bump2version

Version-bump your software with a single command
https://pypi.python.org/pypi/bump2version
MIT License
1.06k stars 134 forks source link

Unexpected handling of unknown parts #138

Closed matthijskooijman closed 4 years ago

matthijskooijman commented 4 years ago

I just tried bump2version on a project I inherited, and it behaved a little bit surprising when I passed a non-existent "part". Of course the problem was that I read the docs too fast and remembered "revision" rather than "patch", but the lack of error message made me think I remembered correctly.

From reading some issues here, I understand that this has somewhat become a feature to work around #22, but I still think it warrants a separate issue and fixing.

First off, it seems that without further configuration, an unknown part simply does nothing (except when --new-version is supplied, in which case I guess the part is not used at all):

matthijs@grubby:~$ echo 1.0.0 > VERSION
matthijs@grubby:~$ bump2version --current-version 1.0.0 patch VERSION
matthijs@grubby:~$ cat VERSION 
1.0.1
matthijs@grubby:~$ bump2version --current-version 1.0.1 foo VERSION
matthijs@grubby:~$ cat VERSION 
1.0.1

matthijs@grubby:~$ bump2version --current-version 1.0.1 --new-version 1.0.2 foo VERSION
matthijs@grubby:~$ cat VERSION 
1.0.2

On particularly weird version of this is with a search replace config:

matthijs@grubby:~/docs/src/upstream/hamster$ cat .bumpversion.cfg 
[bumpversion]
current_version = 3.0.1

[bumpversion:file:wscript]
search = VERSION = "{current_version}"
replace = VERSION = "{new_version}"
matthijs@grubby:~/docs/src/upstream/hamster$ bump2version foo
matthijs@grubby:~/docs/src/upstream/hamster$ git diff
diff --git a/wscript b/wscript
index d2c77413..f6bb28b0 100644
--- a/wscript
+++ b/wscript
@@ -8,7 +8,7 @@ from waflib import Utils

 # slight code duplication with hamster/__init__.py, but this is finally cleaner.
 rc, output = getstatusoutput("git describe --tags --always --dirty=+")
-VERSION = "3.0.1" if rc else output
+VERSION = "VERSION = "3.0.1"" if rc else output

 APPNAME = 'hamster'

It seems that somehow only the version number is replaced, rather than the entire search match, but with ${new_version} to the old version. Note that .bumpversion.cfg is also not updated. I get exactly the same result when specifying a correct part and new-version (e.g. bump2version --new-version 3.0.1 patch). I also tried changing replace to replace = VERSION2 = "{new_version}", to see whether it used the search or replace part in the output, but then the problem went away (it would replace VERSION by VERSION2, but nothing else).

OTOH, when omitting the new version, the results are correct (and .bumpversion.cfg is updated):

matthijs@grubby:~/docs/src/upstream/hamster$ bump2version patch
matthijs@grubby:~/docs/src/upstream/hamster$ git diff
diff --git a/.bumpversion.cfg b/.bumpversion.cfg
index 7c8607c2..2aa825e7 100644
--- a/.bumpversion.cfg
+++ b/.bumpversion.cfg
@@ -1,5 +1,5 @@
 [bumpversion]
-current_version = 3.0.1
+current_version = 3.0.2

 [bumpversion:file:wscript]
 search = VERSION = "{current_version}"
diff --git a/wscript b/wscript
index d2c77413..292408d7 100644
--- a/wscript
+++ b/wscript
@@ -8,7 +8,7 @@ from waflib import Utils

 # slight code duplication with hamster/__init__.py, but this is finally cleaner.
 rc, output = getstatusoutput("git describe --tags --always --dirty=+")
-VERSION = "3.0.1" if rc else output
+VERSION = "3.0.2" if rc else output

 APPNAME = 'hamster'

A related but different issue is this backtrace when specifying a new-version, but not a current-version. If this is not supported, it should probably just tell me that :-)

matthijs@grubby:~$ bump2version --new-version 1.0.2 foo VERSION
Traceback (most recent call last):
  File "/home/matthijs/.local/bin/bump2version", line 10, in <module>
    sys.exit(main())
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/cli.py", line 103, in main
    _check_files_contain_version(files, current_version, context)
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/cli.py", line 583, in _check_files_contain_version
    f.should_contain_version(current_version, context)
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/utils.py", line 42, in should_contain_version
    context["current_version"] = self._versionconfig.serialize(version, context)
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/version_part.py", line 278, in serialize
    version, self._choose_serialize_format(version, context), context
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/version_part.py", line 258, in _choose_serialize_format
    version, serialize_format, context, raise_if_incomplete=True
  File "/home/matthijs/.local/lib/python3.7/site-packages/bumpversion/version_part.py", line 201, in _serialize
    for k in version:
TypeError: 'NoneType' object is not iterable
4hopp commented 4 years ago

Same problem here; unknown parts should probably just result in a useful error message.

hartzell commented 4 years ago

I'm also seeing it, but I'm doing the unknown part thing on purpose, using it to manage -rc0 suffixes patterened on