more renaming

storybookjs · Oct 4, 2023 · 15b5933 · 15b5933
1 parent ca7f6f8
commit 15b5933
Show file tree

Hide file tree

Showing 4 changed files with 64 additions and 64 deletions.
diff --git a/.github/workflows/prepare-non-patch-release.yml b/.github/workflows/prepare-non-patch-release.yml
@@ -34,7 +34,7 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-  prepare-next-pull-request:
+  prepare-non-patch-pull-request:
     name: Prepare prerelease pull request
     runs-on: ubuntu-latest
     environment: release
@@ -122,15 +122,15 @@ jobs:
         run: |
           yarn release:write-changelog ${{ steps.bump-version.outputs.next-version }} --verbose
 
-      - name: 'Commit changes to branch: version-next-from-${{ steps.bump-version.outputs.current-version }}'
+      - name: 'Commit changes to branch: version-non-patch-from-${{ steps.bump-version.outputs.current-version }}'
         working-directory: .
         run: |
           git config --global user.name 'storybook-bot'
           git config --global user.email '[email protected]'
-          git checkout -b version-next-from-${{ steps.bump-version.outputs.current-version }}
+          git checkout -b version-non-patch-from-${{ steps.bump-version.outputs.current-version }}
           git add .
           git commit -m "Write changelog for ${{ steps.bump-version.outputs.next-version }} [skip ci]" || true
-          git push --force origin version-next-from-${{ steps.bump-version.outputs.current-version }}
+          git push --force origin version-non-patch-from-${{ steps.bump-version.outputs.current-version }}
 
       - name: Resolve merge-conflicts with base branch
         if: steps.is-prerelease.outputs.prerelease == 'true'
@@ -140,7 +140,7 @@ jobs:
           git pull origin latest-release
           git checkout --ours .
           git add .
-          git commit -m "Merge latest-release into version-next-from-${{ steps.bump-version.outputs.current-version }} with conflicts resolved to ours [skip ci]"
+          git commit -m "Merge latest-release into version-non-patch-from-${{ steps.bump-version.outputs.current-version }} with conflicts resolved to ours [skip ci]"
 
       - name: Generate PR description
         id: description
@@ -166,7 +166,7 @@ jobs:
               --title "Release: $CAPITALIZED_RELEASE_TYPE ${{ inputs.pre-id && format('{0} ', inputs.pre-id) }}${{ steps.bump-version.outputs.next-version }}" \
               --label "release" \
               --base ${{ steps.is-prerelease.outputs.prerelease == 'true' && 'next-release' || 'latest-release' }} \
-              --head version-next-from-${{ steps.bump-version.outputs.current-version }} \
+              --head version-non-patch-from-${{ steps.bump-version.outputs.current-version }} \
               --body "${{ steps.description.outputs.description }}"
           fi
 

diff --git a/CONTRIBUTING/RELEASING.md b/CONTRIBUTING/RELEASING.md
@@ -8,8 +8,8 @@
 - [Introduction](#introduction)
   - [Branches](#branches)
 - [Release Pull Requests](#release-pull-requests)
-  - [Non-patch-releases](#non-patch-releases)
   - [Patch Releases](#patch-releases)
+  - [Non-patch Releases](#non-patch-releases)
   - [Publishing](#publishing)
 - [👉 How to Release](#-how-to-release)
   - [1. Find the Prepared Pull Request](#1-find-the-prepared-pull-request)
@@ -45,7 +45,7 @@
 
 This document explains the release process for the Storybook monorepo. There are two types:
 
-1. non-patch-releases - releasing any content that is on the `next` branch, either prereleases or stable releases
+1. Non-patch releases - releasing any content that is on the `next` branch, either prereleases or stable releases
 2. Patch releases - picking any content from `next` to `main`, that needs to be patched back to the current stable minor release
 
 The release process is based on automatically created "Release Pull Requests", that when merged will trigger a new version to be released.
@@ -57,7 +57,7 @@ A designated Releaser -- which may rotate between core team members -- will go t
 - [Publish](../.github/workflows/publish.yml)
 
 > **Note**
-> This document distinguishes between **non-patch-releases** and **patch** releases. The distinction reflects the difference between patching an existing minor version on `main` or releasing a new minor/major/prerelease from `next`.
+> This document distinguishes between **patch** and **non-patch** releases. The distinction reflects the difference between patching an existing minor version on `main` or releasing a new minor/major/prerelease from `next`.
 
 ### Branches
 
@@ -103,7 +103,7 @@ Two GitHub Actions workflows automatically create release pull requests, one for
 The high-level flow is:
 
 1. When a PR is merged to `next` (or a commit is pushed), both release pull requests are (re)generated.
-2. They create a new branch - `version-(patch|next)-from-<CURRENT-VERSION>`.
+2. They create a new branch - `version-(patch|non-patch)-from-<CURRENT-VERSION>`.
 3. They calculate which version to bump to according to the version strategy.
 4. They update `CHANGELOG(.prerelease).md` with all changes detected.
 5. They commit everything.
@@ -117,48 +117,6 @@ A few key points to note in this flow:
 - The changelogs are committed during the preparation, but the packages are not version bumped and not published until later.
 - The release pull requests don't target their working branches (`next` and `main`), but rather `next-release` and `latest-release`.
 
-### Non-patch-releases
-
-> **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`.
-
-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.
-
-`next`-PRs are only created if there are actual changes to release. Content labeled with "build" or "documentation" is [not considered "releasable"](#which-changes-are-considered-releasable-and-what-does-it-mean) and is not user-facing, so it doesn't make sense to create a release. This is explained in more detail in [Why are no release PRs being prepared?](#why-are-no-release-prs-being-prepared).
-
-The preparation workflow will create a new branch from `next`, called `version-next-from-<CURRENT-NEXT-VERSION>`, and open a pull request targeting `next-release`. When the Releaser merges it, the [publish workflow](#publishing) will merge `next-release` into `next`.
-
-Here's an example of a workflow where a feature and a bugfix have been created and then released to a new `7.1.0-alpha.29` version. All the commits highlighted with square dots are the ones that will be considered when generating the changelog.
-
-```mermaid
-%%{init: { 'gitGraph': { 'mainBranchName': 'next' } } }%%
-gitGraph
-    commit
-    branch next-release
-    commit tag: "7.1.0-alpha.28"
-    checkout next
-    merge next-release
-    commit type: HIGHLIGHT id: "direct commit"
-    branch new-feature
-    commit
-    commit
-    checkout next
-    merge new-feature type: HIGHLIGHT
-    branch some-bugfix
-    commit
-    checkout next
-    merge some-bugfix type: HIGHLIGHT
-    branch version-next-from-7.1.0-alpha.28
-    commit id: "write changelog"
-    checkout next-release
-    merge version-next-from-7.1.0-alpha.28
-    commit id: "bump versions" tag: "7.1.0-alpha.29"
-    checkout next
-    merge next-release
-```
-
 ### Patch Releases
 
 > **Note**
@@ -210,6 +168,48 @@ gitGraph
     merge latest-release
 ```
 
+### Non-patch Releases
+
+> **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`.
+
+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.
+
+`next`-PRs are only created if there are actual changes to release. Content labeled with "build" or "documentation" is [not considered "releasable"](#which-changes-are-considered-releasable-and-what-does-it-mean) and is not user-facing, so it doesn't make sense to create a release. This is explained in more detail in [Why are no release PRs being prepared?](#why-are-no-release-prs-being-prepared).
+
+The preparation workflow will create a new branch from `next`, called `version-non-patch-from-<CURRENT-NEXT-VERSION>`, and open a pull request targeting `next-release`. When the Releaser merges it, the [publish workflow](#publishing) will merge `next-release` into `next`.
+
+Here's an example of a workflow where a feature and a bugfix have been created and then released to a new `7.1.0-alpha.29` version. All the commits highlighted with square dots are the ones that will be considered when generating the changelog.
+
+```mermaid
+%%{init: { 'gitGraph': { 'mainBranchName': 'next' } } }%%
+gitGraph
+    commit
+    branch next-release
+    commit tag: "7.1.0-alpha.28"
+    checkout next
+    merge next-release
+    commit type: HIGHLIGHT id: "direct commit"
+    branch new-feature
+    commit
+    commit
+    checkout next
+    merge new-feature type: HIGHLIGHT
+    branch some-bugfix
+    commit
+    checkout next
+    merge some-bugfix type: HIGHLIGHT
+    branch version-non-patch-from-7.1.0-alpha.28
+    commit id: "write changelog"
+    checkout next-release
+    merge version-non-patch-from-7.1.0-alpha.28
+    commit id: "bump versions" tag: "7.1.0-alpha.29"
+    checkout next
+    merge next-release
+```
+
 ### Publishing
 
 > **Note**
@@ -304,7 +304,7 @@ The workflows can be triggered here:
 - [Prepare next PR](https://github.com/storybookjs/storybook/actions/workflows/prepare-non-patch-release.yml)
 - [Prepare patch PR](https://github.com/storybookjs/storybook/actions/workflows/prepare-patch-release.yml)
 
-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 prerelease workflow manually, you can optionally add inputs:
+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 prerelease 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)
 
@@ -435,7 +435,7 @@ There are multiple types of releases that use the same principles, but are done
 
 ### Prereleases - `7.1.0-alpha.12` -> `7.1.0-alpha.13`
 
-This is the default strategy for non-patch-releases, there's nothing special needed to trigger this scenario.
+This is the default strategy for Non-patch releases, there's nothing special needed to trigger this scenario.
 
 ### Prerelease promotions - `7.1.0-alpha.13` -> `7.1.0-beta.0`
 
@@ -451,7 +451,7 @@ To promote a prerelease to a stable reelase, during the [Re-trigger the Workflow
 - Release type: Patch, Minor or Major
 - Prerelease ID: Leave empty
 
-This scenario is special as it will target `latest-release` instead of `next-release`, and thus merge into `main` when done, and not `next`. So it goes `next` -> `version-from-<CURRENT-VERSION-ON_NEXT` -> `latest-release` -> `main`.
+This scenario is special as it will target `latest-release` instead of `next-release`, and thus merge into `main` when done, and not `next`. So it goes `next` -> `version-non-patch-from-<CURRENT-VERSION-ON_NEXT>` -> `latest-release` -> `main`.
 
 ### First prerelease of new major/minor - `7.1.0` -> `7.2.0-alpha.0` or `8.0.0-alpha.0`
 
@@ -538,7 +538,7 @@ If a pull request does not have any of the above labels at the time of release,
 
 This is most likely because `next` only contains [unreleasable changes](#which-changes-are-considered-releasable-and-what-does-it-mean), which causes the preparation workflow to cancel itself. That's because it doesn't make sense to prepare a new release if all the changes are unreleasable, as that wouldn't bump the version nor write a new changelog entry, so "releasing" it would just merge it back to `next` without any differences.
 
-You can always see the workflows and if they have been cancelled [here for non-patch-releases](https://github.com/storybookjs/storybook/actions/workflows/prepare-non-patch-release.yml) and [here for patch releases](https://github.com/storybookjs/storybook/actions/workflows/prepare-patch-release.yml).
+You can always see the workflows and if they have been cancelled [here for non-patch releases](https://github.com/storybookjs/storybook/actions/workflows/prepare-non-patch-release.yml) and [here for patch releases](https://github.com/storybookjs/storybook/actions/workflows/prepare-patch-release.yml).
 
 ### Why do we need separate release branches?
 
@@ -560,11 +560,11 @@ gitGraph
     branch some-simultaneous-bugfix
     commit
     checkout next
-    branch version-next-from-7.1.0-alpha.28
+    branch version-non-patch-from-7.1.0-alpha.28
     commit id
     checkout next
     merge some-simultaneous-bugfix type: HIGHLIGHT id: "whoops!"
-    merge version-next-from-7.1.0-alpha.28 tag: "v7.1.0-alpha.29"
+    merge version-non-patch-from-7.1.0-alpha.28 tag: "v7.1.0-alpha.29"
 ```
 
 When publishing at the last commit with tag `v7.1.0-alpha.29`, it will publish whatever the content is at that point (all the square dots), which includes the "whoops!" commit from merging the bugfix. But the bugfix was never part of the release pull request because it got prepared before the bugfix was merged in.
@@ -584,19 +584,19 @@ gitGraph
     branch some-simultanous-bugfix
     commit
     checkout next
-    branch version-next-from-7.1.0-alpha.28
+    branch version-non-patch-from-7.1.0-alpha.28
     commit id: "write changelog"
     checkout next
     merge some-simultanous-bugfix id: "whoops!"
     checkout next-release
-    merge version-next-from-7.1.0-alpha.28
+    merge version-non-patch-from-7.1.0-alpha.28
     commit id: "bump versions" tag: "v7.1.0-alpha.29"
     checkout next
     merge next-release
-    branch version-next-from-7.1.0-alpha.29
+    branch version-non-patch-from-7.1.0-alpha.29
     commit id: "write changelog again"
     checkout next-release
-    merge version-next-from-7.1.0-alpha.29
+    merge version-non-patch-from-7.1.0-alpha.29
     commit id: "bump versions again" tag: "v7.1.0-alpha.30"
     checkout next
     merge next-release

diff --git a/scripts/release/__tests__/is-pr-frozen.test.ts b/scripts/release/__tests__/is-pr-frozen.test.ts
@@ -64,7 +64,7 @@ describe('isPrFrozen', () => {
     });
     await isPrFrozen({ patch: false });
 
-    expect(simpleGit.__fetch).toHaveBeenCalledWith('origin', 'version-next-from-1.0.0', {
+    expect(simpleGit.__fetch).toHaveBeenCalledWith('origin', 'version-non-patch-from-1.0.0', {
       '--depth': 1,
     });
   });

diff --git a/scripts/release/is-pr-frozen.ts b/scripts/release/is-pr-frozen.ts
@@ -46,7 +46,7 @@ export const run = async (options: unknown) => {
   const { verbose, patch } = options as { verbose?: boolean; patch?: boolean };
 
   const version = await getCurrentVersion();
-  const branch = `version-${patch ? 'patch' : 'next'}-from-${version}`;
+  const branch = `version-${patch ? 'patch' : 'non-patch'}-from-${version}`;
 
   console.log(`💬 Determining if pull request from branch '${chalk.blue(branch)}' is frozen`);