-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-line replace
doesn't work for lines starting with #
#199
Comments
I've run into the same issue. Trying to adopt the For the time being, I'm using the following as a workaround:
and will plan to simply delete the leading dash manually upon the next edit. |
This seems to be due to configparser module used by bumpversion. configparser kindly discards all new lines in the replace string beginning with # as comments. For "Keep a Changelog" to be supported as is, one might need a remedy for that. |
The # in Markdown gets treated as a comment so there is no way to do multiline search/replace. As a result only a single line with the version number is replaced. The # Latest headline will have to be added manually on the next set of changes. See peritus/bumpversion#199
Using python 3.6 and bumpversion v0.5.3.
Great tool!
Summary
#
character to avoid the line being treated as a comment\n
in thereplace
field does not replace the sequence with a newline but with the literal\n
Detail
The following blurb in
.bumpversion.cfg
should replace the## vNEXT
header in theCHANGELOG.md
file with the same header, a new line and a## v{new_version}
line.However the CHANGELOG file is not modified and the 2nd and 3rd lines of the
replace
field in the.bumpversion.cfg
file are deleted.The same
.bumpversion.cfg
section after runningbumpversion minor --no-tag
:It's not a multi-line problem since using
*
instead of#
works as expected, e.g. with the following:I've tried escaping the
#
using\#
to but that writes the actual\#\#
characters in the CHANGELOG.I've tried using a single-line replace with
\n
for the new line but as before, the actual character\n
is what appears in the CHANGELOG.I've tried using
{\n}
instead but that just raises aKeyError: '\\n'
.Full log:
The text was updated successfully, but these errors were encountered: