Release Process
Pushing a new release
The steps vary slightly depending on the type of release you are pushing (major, minor or patch)
To release a new patch version (eg. from 0.28.1 to 0.28.2)
- Cherry-pick all required changes to the
-stable
branch (eg.0.28-stable
for 0.28). - Ensure you are on the
-stable
branch locally. - Run
npm version patch
to bump the version number, and create the Git commit and tag - Run
git push origin 0.xx-stable --follow-tags
(replace0.xx-stable
with the right branch name)
To release a new minor or major version (eg. from 0.28.x to 0.29.0)
- Make sure current master branch is green on Circle, Travis and AppVeyor
- Ensure you are on
master
and your local copy of Yarn is up-to-date - Run
./scripts/release-branch.sh
. This will:- Create the
0.xx-stable
branch and0.xx.0
tag - Bump
master
to the next minor version (eg. after releasing0.29.0
, master will be bumped to0.30.0
) - Push it all to
origin
- Create the
To mark an RC release as stable
Once an RC has been tested by the community for a while and all major bugs have been ironed out, it can be marked as stable. To do this, go to https://release.yarnpkg.com/ and click the “Promote RC to stable” button.
Note: There is a whitelist for the users that are able to access this page. If a maintainer is missing from the whitelist, you can modify it here.
Debugging a release
Sometimes things go wrong. Here’s how to debug some common issues:
I’ve committed the tag but the site still points to the old version
Check the GitHub release for any missing artifacts. The release scripts do not bump the version number on the site until both the Linux and the Windows artifacts have been attached to the release.
Linux artifacts (.tar.gz
, .deb
, etc.) are missing
Check the CircleCI build and re-run it if it has failed. If the build succeeded, check the webhook logs for any errors.
Windows artifacts (.msi
) are missing
Check the AppVeyor build and re-run it if it has failed. If the build succeeded, check the webhook logs for any errors.
All artifacts are attached to release, but site still points to old version
Check the yarn-version Jenkins build job and see whether it has failed.
How to do it manually
Most of the release has been automated and is fairly straightforward. Normally, you can just stop reading here. However, if the release tooling ever breaks (or if you like doing things the hard way), you can manually perform the release steps.
Creating a new release
- Run
yarn build-dist && yarn build-deb
to build the release tarball, Debian package, and RPM package - Run
yarn build-dist && yarn build-win-installer
on Windows to build the Windows installer - GPG sign the
.tar.gz
and.js
artifacts:gpg -u 9D41F3C3 --armor --detach-sign yarn-0.xx.xx.tar.gz
This will generate
.asc
files that you should also attach to the release - Authenticode sign the
.msi
artifacts:osslsigncode sign -t http://timestamp.digicert.com -n "Yarn Installer" -i https://yarnpkg.com/ -pkcs12 yarn-20161122.pfx -readpass yarn-20161122.key -h sha1 -in yarn-0.xx.xx-unsigned.msi -out yarn-0.xx.xx.msi osslsigncode sign -t http://timestamp.digicert.com -n "Yarn Installer" -i https://yarnpkg.com/ -pkcs12 yarn-20161122.pfx -readpass yarn-20161122.key -nest -h sha2 -in yarn-0.xx.xx.msi -out yarn-0.xx.xx.msi
- Create new release on GitHub, and attach all artifacts. For the MSI, ensure you attach the signed version!
- Publish the tarball to npm:
npm publish ./artifacts/yarn-v0.xx.xx.tar.gz
- Perform post-release steps below
Bumping RC to stable
- Modify GitHub release to mark it as stable
- Run
npm dist-tag add yarn@0.xx.xx latest
(where0.xx.xx
is the version number being released) - Run post-release steps below
Post-release
- Bump version number in _config.yml on the website
- Run
./scripts/build-chocolatey.ps1
to push to Chocolatey - Run
./scripts/update-homebrew.sh
to push to Homebrew - Debian and CentOS repo should be automatically updated with the latest release within 5 minutes (keep an eye on the commits)