It is common for software releases to include Release Notes that highlights significant improvements and fixes, and often also an accompanying changelog that itemizes all changes at a finer level of detail.
A changelog should be generatable from the commit history, with links to issues, because we generally describe the nature of a change in the commit and link it to the issue that it addresses. This, then, could be published either via GH Pages or some other means for reference for each release.
One important consideration that a solution should address is API or behaviour breaking changes, especially in the incubation phase where these sorts of changes are more common. Perhaps commits that make such changes could be tagged with #apibreak or #breaking or some such that a changelog generator could pick up to highlight these changes and possibly collect them into a "breaking changes" section.
It is common for software releases to include Release Notes that highlights significant improvements and fixes, and often also an accompanying changelog that itemizes all changes at a finer level of detail.
A changelog should be generatable from the commit history, with links to issues, because we generally describe the nature of a change in the commit and link it to the issue that it addresses. This, then, could be published either via GH Pages or some other means for reference for each release.
One important consideration that a solution should address is API or behaviour breaking changes, especially in the incubation phase where these sorts of changes are more common. Perhaps commits that make such changes could be tagged with
#apibreakor#breakingor some such that a changelog generator could pick up to highlight these changes and possibly collect them into a "breaking changes" section.