fix(wip): add test for current breaking change

[woile]

Description

This is a WIP to fix the current BREAKING CHANGE which includes the test that should pass.
Because we don't want to bump, we should provide a fix of the breaking change.
In the meanwhile you can use commitizen<2.17.0

Checklist

• Add test cases to all the changes you introduce
• Run ./script/format and ./script/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

Steps to Test This Pull Request

Additional context

[codecov]

Codecov Report

Merging #372 (f4cbc35) into master (b8bc952) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #372   +/-   ##
=======================================
  Coverage   97.59%   97.59%           
=======================================
  Files          39       39           
  Lines        1373     1373           
=======================================
  Hits         1340     1340           
  Misses         33       33           

Flag	Coverage Δ
unittests	97.59% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
commitizen/__version__.py	100.00% <100.00%> (ø)
commitizen/bump.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b541add...f4cbc35. Read the comment docs.

[woile]

Oh nice @Lee-W ! 💪🏻

[jaysonsantos]

Hey there, sorry to hear that my change broke the tool.
I think this approach could have a problem if the version would have a decimal change like from 9 to 10 as IIRC finditer still holds a reference to an old string

[jaysonsantos]

To reproduce the error you could use this:

diff --git a/tests/test_bump_update_version_in_files.py b/tests/test_bump_update_version_in_files.py
index aebd879..3d289e2 100644
--- a/tests/test_bump_update_version_in_files.py
+++ b/tests/test_bump_update_version_in_files.py
@@ -39,15 +39,39 @@ REPEATED_VERSION_NUMBER = """
 CARGO_LOCK = """
 [[package]]
 name = "textwrap"
-version = "1.2.3"
+version = "1.2.9"
 
 [[package]]
 name = "there-i-fixed-it"
-version = "1.2.3"
+version = "1.2.9"
 
 [[package]]
 name = "other-project"
-version = "1.2.3"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
+
+[[package]]
+name = "other-project"
+version = "1.2.9"
 """
 
 
@@ -115,8 +139,8 @@ def test_partial_update_of_file(version_repeated_file):
 
 
 def test_random_location(random_location_version_file):
-    old_version = "1.2.3"
-    new_version = "2.0.0"
+    old_version = "1.2.9"
+    new_version = "1.2.10"
     location = f"{random_location_version_file}:there-i-fixed-it.+\nversion"
 
     bump.update_version_in_files(old_version, new_version, [location])
@@ -127,8 +151,8 @@ def test_random_location(random_location_version_file):
 
 
 def test_duplicates_are_change_with_no_regex(random_location_version_file):
-    old_version = "1.2.3"
-    new_version = "2.0.0"
+    old_version = "1.2.9"
+    new_version = "1.2.10"
     location = f"{random_location_version_file}:version"
 
     bump.update_version_in_files(old_version, new_version, [location])

i think that a way (hacky though) to fix this would keep and offset variable that gets the string difference from the old version to the new (it can be positive and negative) so you take accountable this kind of problem