maartenbreddels
commented
1 year ago Yes, I agree. Although we do our best to be strict in our commit messages (following conventional commits) it may not be the best interface to browse through changes.
There are a few things that come to mind:
- It should be low friction to the main/core developers
- I think commit messages can be used as basis for a changelog, which will be low friction. Still, I think there are many commit messages that should not be included, the most obvious ones being typos in code or documentation.
A few projects I know
- https://pypi.org/project/towncrier seems to link a issue/PR number to a changelog snippets (seperate file), the snippets will be merged into a larger changelog document, which seems to auto link to the PR/issue. Downside is that before making a PR, you do not know the issue/PR number.
- https://github.com/nedbat/scriv also uses changelog snippets
- https://github.com/vaab/gitchangelog uses a variant of conventional commits that also include the audience. I think this is useful to provide a way to filter out messages targeted to particular audiences (not sure if that is a feature though)
A good discussion item is https://github.com/pypa/build/issues/169#issuecomment-716853727
Also, another point raised by https://github.com/pypa/build/issues/169#issuecomment-717934646 is "Commit messages [snip] are much harder to review than files in the repository."
I've been doing full manual changelog in the past, and that does increase friction by so much that I do not want to do that again without having some helper tools.
More ideas are welcome!
lp9052
As the Solars package gains wider adoption, it becomes increasingly important to provide users with a convenient way to track changes and make informed decisions when selecting versions. Adding release notes would greatly benefit users.