From cbcea150ad13ff0c55b14faa30b4a765396b04ab Mon Sep 17 00:00:00 2001 From: Jeppe Reinhold Date: Mon, 9 Oct 2023 10:13:21 +0200 Subject: [PATCH] fix bad non-patch renaming --- .github/workflows/publish.yml | 2 +- CONTRIBUTING/RELEASING.md | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index df82ca33c9a5..8bb5fa3a82a6 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -5,7 +5,7 @@ on: push: branches: - latest-release - - non-patch-release + - next-release env: PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD: 1 diff --git a/CONTRIBUTING/RELEASING.md b/CONTRIBUTING/RELEASING.md index 7cf29a463c62..d1c4eecdb849 100644 --- a/CONTRIBUTING/RELEASING.md +++ b/CONTRIBUTING/RELEASING.md @@ -124,11 +124,11 @@ A few key points to note in this flow: Patch releases are created by [cherry-picking](https://www.atlassian.com/git/tutorials/cherry-pick) any merged, unreleased pull requests that have the "**patch:yes**" label applied to the `next` branch. The merge commit of said pull requests are cherry-picked. -Sometimes it is desired to pick pull requests back to `main` even if they are not considered "releasable". Unlike non-patch-release preparation, patch releases will not be canceled if the content is not releasable. It might not make sense to create a new patch release if the changes are only for documentation and/or internal build systems. However, getting the changes back to `main` is the only way to deploy the documentation to the production docs site. You may also want to cherry-pick changes to internal CI to fix issues. These are valid scenarios where you want to cherry-pick the changes without being blocked on "releasable" content. In these cases, where all cherry picks are non-releasable, the preparation workflow creates a "merging" pull request instead of a "releasing" pull request. This pull request does not bump versions or update changelogs; it just cherry-picks the changes and allows you to merge them into `latest-release` -> `main`. +Sometimes it is desired to pick pull requests back to `main` even if they are not considered "releasable". Unlike non-patch release preparation, patch releases will not be canceled if the content is not releasable. It might not make sense to create a new patch release if the changes are only for documentation and/or internal build systems. However, getting the changes back to `main` is the only way to deploy the documentation to the production docs site. You may also want to cherry-pick changes to internal CI to fix issues. These are valid scenarios where you want to cherry-pick the changes without being blocked on "releasable" content. In these cases, where all cherry picks are non-releasable, the preparation workflow creates a "merging" pull request instead of a "releasing" pull request. This pull request does not bump versions or update changelogs; it just cherry-picks the changes and allows you to merge them into `latest-release` -> `main`. The preparation workflow sequentially cherry-picks each patch pull request to its branch. If this cherry-picking fails due to conflicts or other reasons, it is ignored and the next pull request is processed. All failing cherry-picks are listed in the release pull request's description, for the Releaser to manually cherry-pick during the release process. This problem occurs more often when `main` and `next` diverge, i.e. the longer it has been since a stable major/minor release. -Similar to the non-patch-release flow, the preparation workflow for patches will create a new branch from `main` called `version-patch-from-`, and open a pull request that targets `latest-release`. When the pull request is merged by the Releaser, the [publish workflow](#publishing) will eventually merge `latest-release` into `main`. +Similar to the non-patch release flow, the preparation workflow for patches will create a new branch from `main` called `version-patch-from-`, and open a pull request that targets `latest-release`. When the pull request is merged by the Releaser, the [publish workflow](#publishing) will eventually merge `latest-release` into `main`. Here is an example of a workflow where a feature and two bug fixes have been merged to `next`. Only the bug fixes have the "**patch:yes**" label, so only those two go into the new `7.0.19` release. Note that it is the merge commits to `next` that are cherry-picked, not the commits on the bugfix branches. @@ -173,7 +173,7 @@ gitGraph > **Note** > Workflow: [`prepare-non-patch-release.yml`](../.github/workflows/prepare-non-patch-release.yml) -Non-patch-releases are prepared with all content from the `next` branch. The changelog is generated by examining the git history, and looking up all the commits and pull requests between the current prerelease (on `next-release`) and `HEAD` of `next`. +Non-patch releases are prepared with all content from the `next` branch. The changelog is generated by examining the git history, and looking up all the commits and pull requests between the current prerelease (on `next-release`) and `HEAD` of `next`. The default versioning strategy is to increase the current prerelease number, as described in [Prereleases - `7.1.0-alpha.12` -> `7.1.0-alpha.13`](#prereleases---710-alpha12---710-alpha13). If there is no prerelease number (i.e., we just released a new stable minor/major version), it will add one to a patch bump, so it would go from `7.2.0` to `7.2.1-0` by default. @@ -215,7 +215,7 @@ gitGraph > **Note** > Workflow: [`publish.yml`](../.github/workflows/publish.yml) -When either a non-patch-release or a patch release branch is merged into `latest-release` or `next-release`, the publishing workflow is triggered. This workflow performs the following tasks: +When either a non-patch release or a patch release branch is merged into `latest-release` or `next-release`, the publishing workflow is triggered. This workflow performs the following tasks: 1. Bump versions of all packages according to the plan from the prepared PRs 2. Install dependencies and build all packages. @@ -306,7 +306,7 @@ The workflows can be triggered here: Crucially for prereleases, this is also where you change the versioning strategy if you need something else than the default as described in [Preparing - Non-patch Releases](#non-patch-releases). When triggering the non-patch workflow manually, you can optionally add inputs: -![Screenshot of triggering the non-patch-release workflow in GitHub Actions, with a form that shows a release type selector and a prerelease identifier text field](prerelease-workflow-inputs.png) +![Screenshot of triggering the non-patch release workflow in GitHub Actions, with a form that shows a release type selector and a prerelease identifier text field](prerelease-workflow-inputs.png) See [Versioning Scenarios](#versioning-scenarios) for a description of each version bump scenario, how to activate it and what it does, and [Which combination of inputs creates the version bump I need?](#which-combination-of-inputs-creates-the-version-bump-i-need) for a detailed description of the workflow inputs. @@ -376,7 +376,7 @@ Before you start you should make sure that your working tree is clean and the re 4. `git add ./CHANGELOG.md` 5. `git commit -m "Update CHANGELOG.md for v"` 6. `git push origin` -19. (If non-patch-release) Sync `versions/next.json` from `next` to `main` +19. (If non-patch release) Sync `versions/next.json` from `next` to `main` 1. `git checkout main` 2. `git pull` 3. `git checkout origin/next ./docs/versions/next.json`