RFC: Publish release notes extensibility

Problem

Release notes can have multiple homes, changesets updates the CHANGELOG.md files in the repo. We then have changesets/action which wraps the CLI tool to create a GitHub release.

This makes the responsibilities of the changeset components a bit difficult to understand. Git tagging is done by the changeset tool, but then the release is published by an external tool. Also the changeset action facilitates a very specific workflow, if you don’t use that workflow then it’s pretty clunky to get GitHub releases published.

Related issues

https://github.com/changesets/changesets/issues/264 https://github.com/changesets/changesets/issues/387

Proposed solution

New extension point which ‘publishes’ the release notes, it is run directly after tagging. I think the word publish is being overloaded though. Maybe we should call this ‘target’ or something else?

This will open up publishing release notes to BitBucket, GitLab or even to JIRA or other tools like Octopus Deploy etc.

Config

  "publish": [
    "@changesets/publish-github",
    { "repo": "changesets/changesets" }
  ],

There are a number of open issues, by splitting out the release notes publication step it would allow config for that package to be introduced, reducing top level config sprawl but also give the escape hatch

Migration

The changeset/action component should detect if the github publisher is not being used and create a note inside the PR to update your config. If it detects the config change has been made, it will no longer create the release because that will be done by changesets itself.

[Andarist]

There is a risk that it creates an ecosystem which feels like cobbling together tooling

This is my concern here - the given new CLI wouldn’t be completely decoupled from Changesets anyway because it would assume how the CHANGELOG.md has been generated, how headings are structured etc.

I somewhat doubt there is a huge demand for this being a separate CLI and I don’t think would get a lot of non-Changesets users. And at that point… what’s the point in separating them? :p

[Andarist]

I’d rename this config option to something like releaseNotes to make it clear what this component is about. One good thing about the current architecture~ is that changesets/action can be used without any further configuration. But perhaps in the future, it could provide the @changesets/release-notes-github as a default somehow. It can also continue working as it does for a considerable future (when changeset/config.json#releaseNotes would be absent).

We also need to figure out what arguments this should receive for it to create those release notes in a clean way.

I’d like to run this RFC by @mitchellhamilton before you get to implementing this - he might have some additional thoughts about this.