Don't fall back to original_version if search pattern is not found

[florisla]

This is one of the areas where bump2version does not work like I expect it to.

If for any reason (user error) the search pattern is not found, it simply assumes that it can replace {current_version} with the new version.

This can lead to incorrect changes (broken files!) as demonstrated in #126. I often encounter this while developing search patterns and when using custom replace patterns.

I think this 'fall-back feature' does more harm than good, and we should drop it.

Given a file version.txt

release = "1.0.0"

And a config

[bumpversion]
current_version = 1.0.0

[bumpversion:file:version.txt]
search = current_release = "{current_version}"
replace = current_release = "{new_version}"

Doing bumpversion patch produces this without any warning:

release = "current_release = 1.0.1"

This is wrong!

[sdementen]

+1

[LefterisJP]

Hey @florisla I am facing the exact same problem for a package-lock.json file and am currently bumping that file's version by hand.

Until your PR is merged and included in a release is there any other way to go around this?

[florisla]

Hi, the problem is that the search expression does not match your package-lock.json file.

This fix does not solve that problem! Instead of producing erratic output, it will simply not bump the version number.

It looks like one can not use whitespace after a newline in the search expression (at least when it's defined in an INI-like config file).

I'm not familiar with a workaround; if you put the advanced expression in parse instead then your current_version and serialize need to be mutilated as well. Not fun.

Unless anyone knows a better option, #48 is what you need.

[LefterisJP]

I see. Thank you for the response @florisla

Handling of json files would be absolutely great! Any way I can help pushing that PR? 😄

[florisla]

@LefterisJP PR #48 needs to be rebased on master and needs some other impovements. Would be great if you could look into it.