Closed TSNoble closed 1 year ago
Confirmed. I tried adding an extra line of white space, and fixing the underlines to have the same length as their headers, but that did not help. Putting the notes above the Changelog header did not help either.
Specifically looking for "(unreleased)" may help for prerelease, but in postrelease we would expect to only find a date. So that way to fix it seems hard.
In general, I think we do not handle MarkDown changelogs well, especially not the hashes for headers. I tried with this (copied and adapted from https://keepachangelog.com/en/1.0.0/, which I did not yet know, but I like it):
# Changelog
## [1.1.0] - unreleased
### Added
- A test.
## [1.0.0] - 2017-06-20
### Added
- Blah
prerelease turned this into:
# Changelog
1.1.0 (2021-05-04)
### Added
- A test.
## [1.0.0] - 2017-06-20
### Added
- Blah
So the hashes in front of 1.1.0 are lost. (Note: we always put the date in brackets, we do not try to adapt to the existing style, here with a dash, as we probably thought that too complicated.)
So a PR would probably need to do be a bigger change for supporting MarkDown in general. Preferably without a hard dependency on a package for reading MarkDown.
If you can figure out a smaller change, that would be fine too. But it would need to work for both prerelease and postrelease to be consistent.
MarkDown support was added today in PR #398. Released in zest.releaser = 7.2.0.
I'm having some issues running
prerelease
with a Changelog that looks like the following:Expected Outcome:
Actual Outcome:
Additional notes:
Removing the links fixes the issue. I suspect it may be due to the fact that they use parentheses, which I think zest uses to determine which line needs updating. Perhaps the logic could be updated to specifically look for "(unreleased)"? Happy to raise a PR if the change sounds sensible