-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Reformat changelog to use reflinks in changelog entries #58
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much cleaner!
Mind: there is one gotcha - when creating a new release and copying the changelog to it, the links to the contributor pages at the bottom of the file will also need to be copied over to the release text.
Just something to be aware of once this PR has been merged.
I think that for that very reason, this change, especially on the changelog, should not be done:
|
@jrfnl no, you don't. GitHub formats issues/pull-requests and usernames anyway, without markdown magic required. this is needed only when you want to render the changelog in view file or outside github. |
@mfn I very strongly disagree, changelog must be readable without a full bloated browser. the changelog is edited by humans, humans make mistakes, if each entry is 300 bytes long, they don't grasp anymore the noise from the data. so copying a wrong username or ticket link is very easy to make. and another opinion, maintaining a changelog file is a band-aid of lacking automation that could take pull requests, issues, and their titles, labels and combine up a release note and generate that release notes on release creation. |
Good points, we've different opinions 👍
Agree! Unfortunately so far I've only seen tools that take literally every commit/PR and add them, making an unreadable mess of things 😢 |
@mfn no, commits are too granular, and you can't edit them prior to release. but pull requests title, and their labels are a very good fit. you can edit (as a maintainer) them prior to release, and classify each pr/issue of change type. this idea is so trivial, and yet I have not found a good project to automate this all. the closest I've come acquainted with is: anyway, the downside of the release notes manual task topic mentioned here does not apply at all. here's some older release, using
|
@grogy ping. this pr is a response to your wish: |
Thanks! It look's too better |
See discussion at #57