Closed delbertooo closed 4 years ago
You might want to mention issues, if there are issues affected by this.
Hi delbertooo, did you see #128 ?
Do you think #128 covers your desired behavior, or is your implementation even more strict
?
Hi, I - in fact - didn't see #128 and #127.
I strongly agree with #127 and going with this would make my feature obsolete. I think I got misled by the fact, that the code of this "fallback feature" is still there but dead now. The side effect, that the existence of the version is checked before replacing makes this code dead (when called from CLI).
TL;DR: I think my code isn't needed if everyone agrees with #127.
Besides that: as you reached the first major version, I would strongly suggest to follow semantic versioning. Introducing #127 and #128 is a breaking change to existing bumpversion derivates and to bump2version itself. I don't think we can declare #127 as a bug, even though it's a pretty useless feature. So IMO this should be part of a new major version with migration notes in a corresponding UPGRADING.md
file. But this topic isn't related to the original issue anymore.
The current behavior of search and replace is:
This may lead to unwanted or strange replacements. As I debugged such unwanted replacements I found a TODO in your code and decided to implement it. The new behavior (with the option enabled) will be:
The implementation is opt-in and should not alter the current behavior of the program at all. If you don't specify the new option, everything will work as it did before.
I suggest bringing this into Version 1.1.0 if you follow semver.