Automate the changelog #710
Conversation
|
Does this imply that we should follow particular conventions in our commit messages? If so, can we document those in the chalk book? I like the general idea, I've been too lazy to adopt a convention like this but it makes sense to me. |
|
I don't think there's a particular convention required. They way I set it up, the changelog items are just the PRs that were merged. |
|
☔ The latest upstream changes (presumably 5fbad64) made this pull request unmergeable. Please resolve the merge conflicts. |
AzureMarker
force-pushed
the
feature/automated-changelog
branch
from
5233284 to
a620608
Compare
|
☔ The latest upstream changes (presumably 6d0ddc5) made this pull request unmergeable. Please resolve the merge conflicts. |
Older versions without tags use "best-effort" commit hashes. The choice of changelog generation tool can be changed if requested.
AzureMarker
force-pushed
the
feature/automated-changelog
branch
from
a620608 to
168c8b2
Compare
|
This is ready for review, whenever someone has time. |
|
@bors r+ |
|
📌 Commit 168c8b2 has been approved by |
|
Seems good! We may want to have some documentation in the chalk book about how the changelogs are generated (actually, it'd be good to document the whole release process!) but that can be done in a follow-up PR. @AzureMarker are you up for that? |
|
☀️ Test successful - checks-actions |
@nikomatsakis Sure, I can look into this. Where would you expect this info to be located? (releases.md, contributing.md, the book, etc) Edit: Oh, I guess that was already answered! |
Update publishing page in the book with automation details In response to #710 (comment), I've added some details about the automated release process to the publishing page in the book.
Older versions without tags use "best-effort" commit hashes.
The choice of changelog generation tool can be changed if requested.
Fixes #665