You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 partand 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
The text was updated successfully, but these errors were encountered:
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):On particularly weird version of this is with a search replace config:
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 correctpart
and new-version (e.g.bump2version --new-version 3.0.1 patch
). I also tried changingreplace
toreplace = VERSION2 = "{new_version}"
, to see whether it used thesearch
orreplace
part in the output, but then the problem went away (it would replaceVERSION
byVERSION2
, but nothing else).OTOH, when omitting the new version, the results are correct (and
.bumpversion.cfg
is updated):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 :-)
The text was updated successfully, but these errors were encountered: