Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected handling of unknown parts #138

Closed
matthijskooijman opened this issue Apr 30, 2020 · 2 comments · Fixed by #168
Closed

Unexpected handling of unknown parts #138

matthijskooijman opened this issue Apr 30, 2020 · 2 comments · Fixed by #168

Comments

@matthijskooijman
Copy link

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
Copy link

4hopp commented May 6, 2020

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

@hartzell
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants