search

taiki-e / parse-changelog

Simple changelog parser, written in Rust.
https://docs.rs/parse-changelog
Apache License 2.0
56 stars 6 forks source link

Links to changes aren't taken into account #34

Open ThomasFrans opened 1 year ago

ThomasFrans commented 1 year ago

When parsing the earliest version of a changelog, links to the actual changes aren't taken into account. The Keep a Changelog format lets you put links at the end which allow the user to navigate to the code changes with a single click.

How to Reproduce

For example with the Keep a Changelog changelog on their website, if you run parse-changelog CHANGELOG.md 0.0.1, it would return the markdown for version 0.0.1, but also all the links at the bottom of the file, which don't actually belong to the changelog for that version, but are general links for all the separate changelogs.

Example

parse-changelog CHANGELOG.md 0.0.1

Current Output

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain.
- README now contains answers to common questions about CHANGELOGs.
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?".

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.1...HEAD
[1.1.1]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0
[0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0
[0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8
[0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7
[0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

Expected Output

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain.
- README now contains answers to common questions about CHANGELOGs.
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?".

PS: Love this tool! Was just about to start something like this myself, but then stumbled upon this.

taiki-e commented 9 months ago

Sorry for the late response.

I think this could be handled better by collecting links separately during parsing and finally checking for links actually used in the text and merging them into the text. (The difficult part would be to properly identify links that span multiple lines of text?)

Since unused links are simply ignored by the viewer, would the current behavior (simply treat the version heading to the next version heading or higher level heading as a single entry) be a practical problem only in a case like "the associated link is not recognized as part of the current entry because it is at the end of the changelog".

ThomasFrans commented 9 months ago

Sorry for the late response.

No problem :slightly_smiling_face:

Since unused links are simply ignored by the viewer, would the current behavior (simply treat the version heading to the next version heading or higher level heading as a single entry) be a practical problem only in a case like "the associated link is not recognized as part of the current entry because it is at the end of the changelog".

I'm not sure I fully understand this part. The unused links are indeed ignored by viewers but they show up when using the tool on the command line to get the changes for a specific version if it happens to be the last version in the changelog (see example in the original issue). I don't know exactly how the Markdown specification defines a link or whether it can span multiple lines. If it can, that would be a bit annoying to parse yes.