It looks like the commits are lightly processed (scanning “type”, removing it, moving it to the correct section/heading), put in bullet points, adding a hyperlink to the commit hash, using section breaks for something (maybe per PR or something).
It looks nice. And verbose. Like a lot of refactoring bullet points.
The “squashed” commits don’t look good but that’s the fault of squash commits (as usual).
In the end this is a very light shim on top of git log. (Light in terms of data, not light in terms of the discipline and visual overhead the so-called Conventional Commits standard demands).
> It looks like the commits are lightly processed (scanning “type”, removing it, moving it to the correct section/heading), put in bullet points, adding a hyperlink to the commit hash, using section breaks for something (maybe per PR or something).
> It looks nice. And verbose. Like a lot of refactoring bullet points.
Most of the bullet points are single features / changes to the library that are delivered to the users of the library.
> The “squashed” commits don’t look good but that’s the fault of squash commits (as usual).
Can you give an example of this? Everything you're seeing in the changelog is a commit that has been pushed to the repo with a title message and a manually crafted body - we generally avoid letting the body be the github squash commit PR message junk.
> In the end this is a very light shim on top of git log. (Light in terms of data, not light in terms of the discipline and visual overhead the so-called Conventional Commits standard demands).
Yeah, and that's generally useful from the perspective that it's available online, searchable in a single doc (which makes it easy to answer questions like "when was blah implemented"
There's probably a bunch of things that would make this even better, but there's diminishing returns on the effort involved in doing so.
It looks nice. And verbose. Like a lot of refactoring bullet points.
The “squashed” commits don’t look good but that’s the fault of squash commits (as usual).
In the end this is a very light shim on top of git log. (Light in terms of data, not light in terms of the discipline and visual overhead the so-called Conventional Commits standard demands).