2.4 KiB
2.4 KiB
Releasing is a 3-step process.
1. Create a release branch
- Bump a version to the new
-postversion and land achore: cut vX.Y.Z-post versioncommit
./utils/update_version.js vX.Y.Z-post
- On your local machine, create a new branch
release-X.Ybased off the "cutting" commit and land achore: mark vX.Y.Zin the local branch:
git checkout mastergit checkout -b release-X.Y./utils/update_version.js vX.Ynpm run docgit commit -am 'chore: mark vX.Y.Z'
- Push branch to the upstream
git push upstream release-X.Y
Once release branch is pushed, it's last commit will be picked up by our CI/CD:
- make sure commit passes all the bots. If there are any failures, carefully inspect failures to see if these are flakes.
- the
publish_canaryworkflow will publish a@nextversion for the commit - this will be our release candidate. Go manually to it's page on NPM to see what it looks like. Try installing locally.
2. Prepare release notes
-
Version starts with "v", e.g. "vX.Y.Z".
-
Fill "Browser versions".
./utils/print_versions.js
-
Fill "Highlights" if any.
- Be creative.
-
Make sure you fetched tags from the upstream to get latest releases.
git fetch --tags upstream
-
Fill "New APIs" if any.
git diff $(git describe --tags $(git rev-list --tags --max-count=1)):docs/api.md docs/api.md
-
Fill "Breaking API Changes" if any.
git diff $(git describe --tags $(git rev-list --tags --max-count=1)):docs/api.md docs/api.md
-
Fill "Bug fixes".
./utils/list_closed_issues.sh $(git describe --tags $(git rev-list --tags --max-count=1))
-
Fill "Raw notes".
git log --pretty="%h - %s" $(git describe --tags $(git rev-list --tags --max-count=1))..HEAD
-
When making links to the API, copy actual links from GitHub, and not from
api.mdsource - these might be incorrect.- Before publishing, replace
blob/master/docswithblob/vX.Y.Z/docsin all the links.
- Before publishing, replace
-
Use "Save Draft", not "Publish".
3. Publish Release
- Hit "publish release"
Once release is published, the publish_release will kick in and publish package version on NPM.