diff --git a/RELEASE.md b/RELEASE.md index bb382e388..97fd51627 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -109,75 +109,37 @@ There are three release channels that map to branches as follows: 1. Make sure the Target Branch field matches the branch you want to make a release on. 1. If you want to release v0.12.0, the target branch must be v0.12 1. If this is the first release on the branch (e.g. v0.13.**0**), paste in [this - template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md). Engineering Lead can provide summary contents for release notes if needed. -1. Click "Save Draft", then confirm the release notes look good and the tag name and branch are correct. Go back into edit the release and click "Publish release" when ready. + template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md). Engineering Lead can provide summary contents for release notes if needed. If this is a patch release, review all the commits since the previous release on this branch and add details as needed. +1. Click "Save Draft", then confirm the release notes look good and the tag name and branch are correct. Go back into edit the release and click "Publish release" when ready. *Ensure the release is marked "Pre release" until the Linux binary artifacts appear* ### Update release branch with the next patch version 1. After the new release has been tagged, update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1) with: ``` - scripts/increment-cargo-version.sh patch + $ scripts/increment-cargo-version.sh patch + $ ./scripts/cargo-for-all-lock-files.sh update ``` -1. Rebuild to get an updated version of `Cargo.lock`: - ``` - cargo build - ``` 1. Push all the changed Cargo.toml and Cargo.lock files to the **release branch** with something like: ``` git co -b version_update git ls-files -m | xargs git add - git commit -m 'Update Cargo.toml versions from X.Y.Z to X.Y.Z+1' + git commit -m 'Bump version to X.Y.Z+1' git push -u origin version_update ``` ### Verify release automation success -1. Go to [Solana Releases](https://github.com/solana-labs/solana/releases) and click on the latest release that you just published. Verify that all of the build artifacts are present. This can take up to 90 minutes after creating the tag. -1. The `solana-secondary` Buildkite pipeline handles creating the binary tarballs and updated crates. Look for a job under the tag name of the release: https://buildkite.com/solana-labs/solana-secondary -1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version. +1. Go to [Solana Releases](https://github.com/solana-labs/solana/releases) and click on the latest release that you just published. Verify that all of the build artifacts are present. This can take up to 60 minutes after creating the tag. +1. The `solana-secondary` Buildkite pipeline handles creating the Linux release artifacts and updated crates. Look for a job under the tag name of the release: https://buildkite.com/solana-labs/solana-secondary. The macOS and Windows release artifacts are produced by Travis CI: https://travis-ci.com/github/solana-labs/solana/branches +1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version. This can take 2-3 hours ### Update documentation TODO: Documentation update procedure is WIP as we move to gitbook Document the new recommended version by updating `docs/src/running-archiver.md` and `docs/src/validator-testnet.md` on the release (beta) branch to point at the `solana-install` for the upcoming release version. -### Update software on devnet.solana.com +### Update software on devnet.solana.com/testnet.solama.com/mainnet-beta.solana.com -The testnet running on devnet.solana.com is set to use a fixed release tag -which is set in the Buildkite testnet-management pipeline. -This tag needs to be updated and the testnet restarted after a new release -tag is created. - -#### Update testnet schedules - -Go to https://buildkite.com/solana-labs and click through: Pipelines -> -testnet-management -> Pipeline Settings -> Schedules -Or just click here: -https://buildkite.com/solana-labs/testnet-management/settings/schedules - -There are two scheduled jobs for testnet: a daily restart and an hourly sanity-or-restart. \ -https://buildkite.com/solana-labs/testnet-management/settings/schedules/0efd7856-7143-4713-8817-47e6bdb05387 -https://buildkite.com/solana-labs/testnet-management/settings/schedules/2a926646-d972-42b5-aeb9-bb6759592a53 - -On each schedule: -1. Set TESTNET_TAG environment variable to the desired release tag. - 1. Example, TESTNET_TAG=v0.13.2 -1. Set the Build Branch to the branch that TESTNET_TAG is from. - 1. Example: v0.13 - -#### Restart the testnet - -Trigger a TESTNET_OP=create-and-start to refresh the cluster with the new version - -1. Go to https://buildkite.com/solana-labs/testnet-management -2. Click "New Build" and use the following settings, then click "Create Build" - 1. Commit: HEAD - 1. Branch: [channel branch as set in the schedules] - 1. Environment Variables: -``` -TESTNET=testnet -TESTNET_TAG=[same value as used in TESTNET_TAG in the schedules] -TESTNET_OP=create-and-start -``` +... ### Alert the community