This is a list of the things that need to happen during a release.
- Open the associated milestone. All issues and PRs should be closed. If they are not you should reassign all open issues and PRs to future milestones.
- Go through the commit history since the last release. Ensure that all PRs
that have landed are marked with the milestone. You can use this to
show all the PRs that are merged on or after YYY-MM-DD:
https://github.com/issues?q=repo%3Acloudflare%2Fkv-asset-handler+merged%3A%3E%3DYYYY-MM-DD
- Go through the closed PRs in the milestone.
- Add this release to the
CHANGELOG.md
. Use the structure of previous entries. If you use VS Code, you can use this snippet to insert new changelog sections. If it is a release candidate, no official changelog is needed, but testing instructions will be added later in the process.
- Create a new branch "#.#.#" where "#.#.#" is this release's version (release) or "#.#.#-rc.#" (release candidate)
- Push up a commit with the
CHANGELOG.md
changes. The commit message can just be "#.#.#" (release) or "#.#.#-rc.#" (release candidate) - Request review from the @cloudflare/workers-devexp team.
Most of your comments will be about the changelog. Once the PR is finalized and approved...
- If you made changes, squash or fixup all changes into a single commit.
- Run
git push
and wait for CI to pass.
- Once ready to merge, tag the commit by running either
git tag -a v#.#.# -m #.#.#
- Run
git push --tags
. - Wait for CI to pass.
Draft a new release on the releases page and update release notes.
Full releases are tagged latest
. If for some reason you mix up the commands below, follow the troubleshooting guide.
- If this is a full release,
cd npm && npm publish
. If it is a release candidate,cd npm && npm publish --tag beta
- Tweet.
- Create a new branch in worker-sites-init
- Update the version of
@cloudflare/kv-asset-handler
if necessary inpackage.json
- Run
npm update
- Commit and create a PR
- Repeat the process in worker-sites-template in the
workers-site
subdirectory
Mistakes happen. Most of these release steps are recoverable if you mess up. The goal is not to, but if you find yourself cursing a fat fingered command, here are some troubleshooting tips. Please feel free to add to this guide.
Tags and releases can be removed in GitHub. First, remove the remote tag:
git push --delete origin tagname
This will turn the release into a draft
and you can delete it from the edit page.
Make sure you also delete the local tag:
git tag --delete vX.X.X