Releasing changes to the deps.cloud ecosystem is a rather easy task. However, it requires some expertise with the system and tool chain should anything go wrong. This document outlines the general approach used to release new versions of the project.
Before releasing the project, here are a few things to check before performing a release.
- Ensure all builds are passing on the main branch
- Permissions to push to
main - Permissions to push a tag
To release a new version of the deps.cloud source, you simply need to push a tag.
- Create a new version:
npm version <patch|minor|major> - Push new tag:
git push --follow-tags - While the builds progress, take some time to write up release notes. Once the tag workflows complete, you should be free to update the release.
Most release notes are auto-generated today.
When we introduce a major feature, we write a small markdown file to provide a summary.
Then at build time, we use a combination of hand written feature announcements and auto-detected fixes to generate notes.
To get a better idea for how this works, see the ./scripts/gen-changelog.sh script.
One task that is currently manual is tracking down the GitHub handles for contributors to a release.
Once a release is complete, there are some post-release tasks to complete.
- Update deployment configuration to use newer images. (depscloud/deploy)
- Write a blog post to advertise the new release. (depscloud/deps.cloud)
- Write a blog post to advertise any new features. (depscloud/deps.cloud)
In order to become a release manager, you will need to:
- Express interest
- Be an active contributor
- Participate in several releases