Closed ionrock closed 10 years ago
Ouch. Yes, there should be the ability to safeguard against that. I think the proposed solution mentioned in https://github.com/peritus/bumpversion/issues/41#issuecomment-38450021 would also address this, so that
search = MyProject=={current_version}
replace = MyProject=={new_version}
in the configuration makes sure that only lines matching "MyProject==" will be changed by bumpversion.
I think I will have time to address this (and the other issues that have been piling up) in the following weeks, but pull requests are always welcome.
Thanks for the report!
@peritus Thank you for the fast response!
I think that would work, but it would be best if that change were per-file, which you've outlined that already in #37.
I started looking at a patch and the tests were not passing. Would you be open to some refactoring in the test suite? I'll see what I can do and you can let me know if you hate it or not ;)
If there is a common workaround for this sort of thing you seen others use please let me know.
Thanks for bumpversion!
Sure! If you could make sure that each aspect has its own commit to simplify reviewing, that would be terrific!
This will be part of the upcoming version 0.5 — which you can install by running
sudo pip install https://github.com/peritus/bumpversion/archive/master.zip#egg=bumpversion-dev
I'd appreciate any testing before the release. Please note the new configuration format (documented in the README)
@peritus everything worked as expected. Thanks!
Our project went from 1.5.6 to 1.5.7. We were using
Django>=1.5.6,<1.6
in oursetup.py
and noticed the Django version had been getting bumped whenever we ran bumpversion.There might be an obvious solution to this already and we just need to change our workflow to avoid this sort of collision. I expect it will happen in other files such as a requirements.txt that we use in deployment.