diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml index 129f4c83d..6a2a5c934 100644 --- a/.github/workflows/docker.yml +++ b/.github/workflows/docker.yml @@ -6,8 +6,10 @@ on: branches: - main tags: - - "v[0-9]+.[0-9]+.[0-9]+" # Push events to matching v*, i.e. v1.0, v20.15.10 - - "v[0-9]+.[0-9]+.[0-9]+-rc*" # Push events to matching v*, i.e. v1.0-rc1, v20.15.10-rc5 + - "v[0-9]+.[0-9]+.[0-9]+" # Push events to matching v*, i.e. v1.0, v20.15.10 + - "v[0-9]+.[0-9]+.[0-9]+-alpha.[0-9]+" # e.g. v0.37.0-alpha.1, v0.38.0-alpha.10 + - "v[0-9]+.[0-9]+.[0-9]+-beta.[0-9]+" # e.g. v0.37.0-beta.1, v0.38.0-beta.10 + - "v[0-9]+.[0-9]+.[0-9]+-rc[0-9]+" # e.g. v0.37.0-rc1, v0.38.0-rc10 jobs: build: diff --git a/.github/workflows/pre-release.yml b/.github/workflows/pre-release.yml new file mode 100644 index 000000000..e8c640d05 --- /dev/null +++ b/.github/workflows/pre-release.yml @@ -0,0 +1,40 @@ +name: "Pre-release" + +on: + push: + tags: + - "v[0-9]+.[0-9]+.[0-9]+-alpha.[0-9]+" # e.g. v0.37.0-alpha.1, v0.38.0-alpha.10 + - "v[0-9]+.[0-9]+.[0-9]+-beta.[0-9]+" # e.g. v0.37.0-beta.1, v0.38.0-beta.10 + - "v[0-9]+.[0-9]+.[0-9]+-rc[0-9]+" # e.g. v0.37.0-rc1, v0.38.0-rc10 + +jobs: + goreleaser: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v3 + with: + fetch-depth: 0 + + - uses: actions/setup-go@v3 + with: + go-version: '1.18' + + - name: Build + uses: goreleaser/goreleaser-action@v3 + if: ${{ github.event_name == 'pull_request' }} + with: + version: latest + args: build --skip-validate # skip validate skips initial sanity checks in order to be able to fully run + + # Link to CHANGELOG_PENDING.md as release notes. + - run: echo https://github.com/tendermint/tendermint/blob/${GITHUB_REF#refs/tags/}/CHANGELOG_PENDING.md > ../release_notes.md + + - name: Release + uses: goreleaser/goreleaser-action@v3 + if: startsWith(github.ref, 'refs/tags/') + with: + version: latest + args: release --rm-dist --release-notes=../release_notes.md + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/.goreleaser.yml b/.goreleaser.yml index 28c6a017d..1f43b420a 100644 --- a/.goreleaser.yml +++ b/.goreleaser.yml @@ -25,6 +25,7 @@ checksum: algorithm: sha256 release: + prerelease: auto name_template: "{{.Version}} (WARNING: BETA SOFTWARE)" archives: diff --git a/RELEASES.md b/RELEASES.md index 751b4f1f1..ae6650e67 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -114,53 +114,66 @@ After doing these steps, go back to `main` and do the following: [e2e]: https://github.com/tendermint/tendermint/blob/main/.github/workflows/e2e-nightly-main.yml -## Release candidates +## Pre-releases Before creating an official release, especially a minor release, we may want to -create a release candidate (RC) for our friends and partners to test out. We use -git tags to create RCs, and we build them off of backport branches. +create an alpha or beta version, or release candidate (RC) for our friends and +partners to test out. We use git tags to create pre-releases, and we build them +off of backport branches, for example: -Tags for RCs should follow the "standard" release naming conventions, with -`-rcX` at the end (for example, `v0.38.0-rc0`). +- `v0.38.0-alpha.1` - The first alpha release of `v0.38.0`. Subsequent alpha + releases will be numbered `v0.38.0-alpha.2`, `v0.38.0-alpha.3`, etc. + + Alpha releases are to be considered the _most_ unstable of pre-releases, and + are most likely not yet properly QA'd. These are made available to allow early + adopters to start integrating and testing new functionality before we're done + with QA. + +- `v0.38.0-beta.1` - The first beta release of `v0.38.0`. Subsequent beta + releases will be numbered `v0.38.0-beta.2`, `v0.38.0-beta.3`, etc. + + Beta releases can be considered more stable than alpha releases in that we + will have QA'd them better than alpha releases, but there still may be + minor breaking API changes if users have strong demands for such changes. + +- `v0.38.0-rc1` - The first release candidate (RC) of `v0.38.0`. Subsequent RCs + will be numbered `v0.38.0-rc2`, `v0.38.0-rc3`, etc. + + RCs are considered more stable than beta releases in that we will have + completed our QA on them. APIs will most likely be stable at this point. The + difference between an RC and a release is that there may still be small + changes (bug fixes, features) that may make their way into the series before + cutting a final release. (Note that branches and tags _cannot_ have the same names, so it's important that these branches have distinct names from the tags/release names.) -If this is the first RC for a minor release, you'll have to make a new backport -branch (see above). Otherwise: +If this is the first pre-release for a minor release, you'll have to make a new +backport branch (see above). Otherwise: 1. Start from the backport branch (e.g. `v0.38.x`). -2. Run the integration tests and the e2e nightlies - (which can be triggered from the Github UI; - e.g., https://github.com/tendermint/tendermint/actions/workflows/e2e-nightly-34x.yml). -3. Prepare the changelog: - - Move the changes included in `CHANGELOG_PENDING.md` into `CHANGELOG.md`. Each RC should have - it's own changelog section. These will be squashed when the final candidate is released. - - Ensure that there is a "release highlights" or "release summary" paragraph - after the version heading describing what we feel are the most important - changes in this release from a user's perspective. This paragraph should - answer the question: "why should users upgrade to this version?", and with - specific reasons (not generic ones like "more bug fixes"). - - Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for - all PRs +2. Run the integration tests and the E2E nightlies + (which can be triggered from the GitHub UI; + e.g., https://github.com/tendermint/tendermint/actions/workflows/e2e-nightly-37x.yml). +3. Prepare the pre-release documentation: + - Ensure that all relevant changes are in the `CHANGELOG_PENDING.md` file. + This file's contents must only be included in the `CHANGELOG.md` when we + cut final releases. - Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes or other upgrading flows. +4. Prepare the versioning: - Bump TMVersionDefault version in `version.go` - Bump P2P and block protocol versions in `version.go`, if necessary. Check the changelog for breaking changes in these components. - Bump ABCI protocol version in `version.go`, if necessary -4. Open a PR with these changes against the backport branch. -5. Once these changes have landed on the backport branch, be sure to pull them back down locally. -6. Once you have the changes locally, create the new tag, specifying a name and a tag "message": - `git tag -a v0.38.0-rc0 -m "Release Candidate v0.38.0-rc0` -7. Push the tag back up to origin: - `git push origin v0.38.0-rc0` +5. Open a PR with these changes against the backport branch. +6. Once these changes have landed on the backport branch, be sure to pull them back down locally. +7. Once you have the changes locally, create the new tag, specifying a name and a tag "message": + `git tag -a v0.38.0-rc1 -m "Release Candidate v0.38.0-rc1` +8. Push the tag back up to origin: + `git push origin v0.38.0-rc1` Now the tag should be available on the repo's releases page. -8. Future RCs will continue to be built off of this branch. - -Note that this process should only be used for "true" RCs -- release candidates -that, if successful, will be the next release. For more experimental "RCs," -create a new, short-lived branch and tag that instead. +9. Future pre-releases will continue to be built off of this branch. ## Minor release @@ -174,10 +187,11 @@ Before performing these steps, be sure the 1. Start on the backport branch (e.g. `v0.38.x`) 2. Run integration tests (`make test_integrations`) and the e2e nightlies. 3. Prepare the release: - - "Squash" changes from the changelog entries for the RCs into a single entry, - and add all changes included in `CHANGELOG_PENDING.md`. - (Squashing includes both combining all entries, as well as removing or simplifying - any intra-RC changes. It may also help to alphabetize the entries by package name.) + - "Squash" changes from the changelog entries for the pre-releases into a + single entry, and add all changes included in `CHANGELOG_PENDING.md`. + (Squashing includes both combining all entries, as well as removing or + simplifying any intra-pre-release changes. It may also help to alphabetize + the entries by package name.) - Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for all PRs - Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes @@ -192,7 +206,7 @@ Before performing these steps, be sure the - `git push origin v0.38.0` 6. Make sure that `main` is updated with the latest `CHANGELOG.md`, `CHANGELOG_PENDING.md`, and `UPGRADING.md`. 7. Add the release to the documentation site generator config (see - [DOCS_README.md](./docs/DOCS_README.md) for more details). In summary: + [DOCS\_README.md](./docs/DOCS_README.md) for more details). In summary: - Start on branch `main`. - Add a new line at the bottom of [`docs/versions`](./docs/versions) to ensure the newest release is the default for the landing page.