Replies: 1 comment
-
In Europa we used release notes in GH: It's something anyone that sends a PR can control, but it's tied to a goreleaser release. In Python, I'm used to look first at a project's doc site for release notes (e.g., Django, Wagtail). If it doesn't exist, then I look for a repo's At least for the core API though (and any other that makes sense), I really like the locked issue that you can subscribe to, and you have a rich editing experience like you said. So 👍 TLDR; since we'll have multiple releases for different components we can mix and match what's more appropriate for each. But using conventional commits and at least giving a short |
Beta Was this translation helpful? Give feedback.
-
We're on the cusp of releasing the first semi-stable version of Dagger's new API + Go SDK. Up until now we've been changing everything constantly, making breaking changes every day, but once we have shipped an API that other folks code against we'll need to be more thoughtful and communicative.
This discussion is just to figure out how and where we should be communicating those changes.
Some points in no particular order:
Some prior art:
CHANGELOG.md
files is a pretty common practice but they're difficult to subscribe to and typically involve a manual separate authoring step. Separate files might be easier to follow than GitHub releases though; GitHub releases can get kind of confusing once you're shipping multiple things from one repo.If you've got other ideas, or know where you'd think to look for these, please share!
Beta Was this translation helpful? Give feedback.
All reactions