Library release process #31
Description
This is a tracking issue for creating an automated release process that can be used by all of our libraries. We may want to split this into smaller tickets.
- Automate changelog generation
- We should automatically generate changelog entries for any changes made since the last release
- The generated changelog should use the "keep a changelog" format.
- Each generated entry will be uncategorized. We will have to manually categorize each entry, and improve the descriptions of each change.
- The entries should be grouped under the release being prepared
- The entry for the release candidate should not have any date. That will be added after it is released.
- Automate npm publishing?
- This is an open question, as there are security concerns about the authority granted to npm tokens.
- Automate preparation of a release candidate
- We could trigger a release candidate by pushing a branch with a particular naming scheme (e.g.
release-X.Y.Z) - The version bump and changelog generation script should be run automatically
- We could trigger a release candidate by pushing a branch with a particular naming scheme (e.g.
- 'Require linear history' should be enabled for any long-running branches (e.g.
mainand version branches)- This lets us assume that it's safe to release after merging the release branch, because it's guaranteed to be identical to what was tested on the release branch.
- Merging the release branch should trigger final release steps
- This includes tagging the release commit, publishing a GitHub release, and updating the changelog with the release date.
- Write instructions for new release process
- These should be included in the repository
- These instructions should assume as little as possible. Include examples of each command that should be run.
- Include instructions for both normal and hotfix releases