minor bug --new-version = old-version

[jeremycarroll]

If you use the --new-version flag with the current version as an argument, bumpversion corrupts the files :(. I ended up with:

version = version = version = 0.2.0

[jeremycarroll]

I wrote a test, and fixed it, but this broke other things such as test_multi_file_configuration2, which looks somewhat odd to me.

[jeremycarroll]

test_multi_file_configuration2 is not just odd, it is incorrect.

Running with the original code inside a debugger we get:

(Pdb) n
> /Users/jeremycarroll/work/bump2version/bumpversion/__init__.py(276)replace()
-> if file_content_before != file_content_after:
(Pdb) p file_content_after
'1.7.0+bob+38944+joe+38943'
(Pdb) 

which, while not desirable behavior, does satisfy the inadequate assertion:

    assert '1.7.1+bob+38945' in tmpdir.join("BUILDNUMBER").read()

[florisla]

This looks suspiciously like #127 but it's not the same bug -- only the same outcome.

What should bumpversion do when new_version == current_version?
Simply don't replace anything and act like everything is OK?

Or fail with a message and return a non-zero error code?

[Pathfinder216]

It would be nice if it moved on as if everything is okay. I ran into this issue while trying to do some automation. I'm trying to write a script that runs bumpversion without committing, grabs the new version and uses it to create a release branch release/<version>, then runs bumpversion again to commit the changes with the proper commit message. If there's a better way to accomplish this, I'm all ears!

Edit: I realized I'm dumb and it won't work like I'm expecting. I now don't have a particular opinion.

[westr029]

Ran into this issue also.

@florisla I would say move on as if everything is OK. I would say you generally call bump2version on purpose, so that you know you are calling it with a similar version. In that case fail bump2version is not necessary. Maybe good to add a warning or so.