Closed philipp-tailor closed 3 years ago
It is exactly the thing I was going to do this weekend =)
I added the workflow to generate changelog from conventional commits. (...and started using such commits from now =)) So now I need to know how to edit messages of pushed commits to proper generate changelog for older versions
Re-writing all commit messages might be possible if you rebase the whole master history, changing all commit hashes. That sounds extremely scary! Two less risky alternatives:
Looks like the github action, which I use, will regenerate whole CHANGELOG.md
from scratch each commit. So I don't know the way to merge it with manually created one.
Oh,ok. Then I'm sure everyone will be content with having one going forward. 🤷
Ha, I tried few actions for changelog generating and there no any I like. One did strange things and I had to rebase repository. Looks like I'll write my own generator. So issue still will be open for a time.
I've seen these two tools being used for conventional commit version & changelog generation. They are not pre-built action, but CI tools easily integrated in github actions: auto, semantic release; there's also release please, which works with release PRs.
The problem is that there no releases - only tags(if i didn't forget run git push --tags
).
Newermind, my changelog generator is almost done. It will generate versions from commits like 0.0.0
(it is default when you run npm version...
) and from tags. Respects conventional commits, but also may add other commits to the changelog. It will work as CLI tool or Github action.
It is how it looks in terminal =)
Finally the CHANGELOG.md is here! Checkout my new tool - Chalogen.
Thank you for a small wonderful router with great docs. 👏🏼
I've been using tinro for a while, and the only friction I've noticed has been keeping it up to date. That's largely because changes are not noted down anywhere. Every time I've been updating tinro I had to scroll over the list of source changes to understand whether adaptions in my projects were required.
Compare this:
To:
While this is no big deal, the absence of a changelog is the only place where the package is not best-in-class.
Possible solutions could be to add a
CHANGELOG.md
, or to use github releases. Either description could be generated manually or automatically - the latter being easier if a machine readable commit structure like conventional commits were being used.I'd be happy to contribute to making it happen, if you deem this worth tackling.