From 4335cac79ca6f47fcbf7c60b749945136c2c4cbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 13:01:18 +0200 Subject: [PATCH 1/9] Update release process documentation --- docs/contributors/code/release.md | 40 ++++++++++++++++--------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index e9dff32206dad3..03bd2b8af737e2 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -12,9 +12,9 @@ To release Gutenberg's npm packages, you need to be part of the [WordPress organ We release a new major version approximately every two weeks. The current and next versions are [tracked in GitHub milestones](https://github.com/WordPress/gutenberg/milestones), along with each version's tagging date (the day when _the release candidate_ is to be tagged). -- **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on. +- **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on. [Preparation of the release post starts here](#writing-the-release-notes-and-post) and spans until the final release. -- **One week after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released, a post [like this](https://make.wordpress.org/core/2019/06/26/whats-new-in-gutenberg-26th-june/) describing the changes and performing a [performance audit](/docs/block-editor/contributors/testing-overview/#performance-testing) is published. +- **One week after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released, the release post is published, including a [performance audit](/docs/block-editor/contributors/testing-overview/#performance-testing). If critical bugs are discovered on stable versions of the plugin, patch versions can be released at any time. @@ -48,20 +48,22 @@ You should check that folks are able to install the new version from their Dashb Once released, all that's left to do is writing a release post on [make.wordpress.org/core](https://make.wordpress.org/core/). You can find some tips on that below. -### Writing the Release Notes and Post +### Documenting the release with the Release Notes and Post -Documenting the release is comprised of the following steps: +
+Documenting the release is a collaborative effort between the release manager, Gutenberg core team developers, and designers, comprised of a series of sequential steps. Because of the amount of people involved and the coordination required, this process needs to adhere to a timeline between the RC and stable releases. +
-1. Curating the changelog -2. Selecting the release highlights -3. Drafting the release post -4. Running the performance tests -5. Publishing the post +1. Curating the changelog - Wednesday after the RC release to Friday +2. Selecting the release highlights - Friday to Monday +3. Drafting the release post - Monday to Wednesday +4. Running the performance tests - Wednesday right after the stable release +5. Publishing the post - Wednesday after stable release #### 1. Curating the changelog The release notes draft is auto-generated by a script that looks for pull requests for the current milestone, and groups them by pull request label. -This is intended to be a starting point for release notes; you will still want to manually review and curate the changelog entries. Because the release candidate changelog is reused in the stable release and it can be a time-consuming process, it is recommended to start this process as soon as the milestone is closed and the release candidate is published. +This is intended to be a starting point for release notes; you will still want to manually review and curate the changelog entries. Because the release candidate changelog is reused in the stable release and it can be a time-consuming process, **it is recommended to start this process as soon as the milestone is closed** and the release candidate is published. Guidelines for proof-reading include: @@ -74,19 +76,21 @@ Guidelines for proof-reading include: #### 2. Selecting the release highlights -Once you have cleaned up the changelog, the next step is to choose a few changes to highlight in the release post. These highlights usually focus on new features and enhancements, including performance and accessibility ones, but can also include important API changes or critical bug fixes. +Once the changelog is cleaned up, the next step is to choose a few changes to highlight in the release post. These highlights usually focus on new features and enhancements, including performance and accessibility ones, but can also include important API changes or critical bug fixes. -Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; it is recommended to make this step a collaborative effort and share your picks with the Gutenberg Core team. +Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; because of this, this step a collaborative effort between the release manager and Gutenberg Core team members. #### 3. Drafting the release post +Because of the nature of the release post content, responsibilities are divided in this step. While the post can either be written by the release manager or delegated to another core member agreed upon in advance, visual assets should be created by the design team. + When possible, the highlighted changes in the release post should include an animation (video or GIF) or a static image of them in use. Choosing between an animation or a static image will depend on the best way to showcase each highlight: while animations are better to demonstrate workflows, more direct highlights can be shown with an image; having too many video players adds a layer of friction for users to see the highlight, whereas too many simultaneous animated GIFs can distract and overwhelm the reader. -These visual assets should maintain consistency with previous release posts; using lean, white themes helps in this regard and visually integrate well with the [make.wordpress.org/core](https://make.wordpress.org/core/) blog aesthetics. Including copyrighted material should be avoided, and browser plugins that can be seen in the browser canvas (spell checkers, form fillers, etc.) disabled when capturing the assets. If you would like help creating the visual assets, please ping somebody in the Gutenberg Core team in advance so that it can be planned for. +These visual assets should maintain consistency with previous release posts; using lean, white themes helps in this regard and visually integrate well with the [make.wordpress.org/core](https://make.wordpress.org/core/) blog aesthetics. Including copyrighted material should be avoided, and browser plugins that can be seen in the browser canvas (spell checkers, form fillers, etc.) disabled when capturing the assets. -#### 4. Running the performance tests +##### 3.3. Running the performance tests -Your post should also include a performance audit at the end, comparing the current Gutenberg release with both the previous one and the latest WordPress major version. There are GitHub worfklows in place to do this comparison as part of the Continuous Integration setup, so the performance audit results can be found at the workflow run generated by the release commit in the [Performance Tests workflows](https://github.com/WordPress/gutenberg/actions/workflows/performance.yml) page, with the job name `Compare performance with current WordPress Core and previous Gutenberg versions`. +The post should also include a performance audit at the end, comparing the current Gutenberg release with both the previous one and the latest WordPress major version. There are GitHub worfklows in place to do this comparison as part of the Continuous Integration setup, so the performance audit results can be found at the workflow run generated by the release commit in the [Performance Tests workflows](https://github.com/WordPress/gutenberg/actions/workflows/performance.yml) page, with the job name `Compare performance with current WordPress Core and previous Gutenberg versions`. If the GitHub workflow fails, the performance audit can be executed locally using `bin/plugin/cli.js perf` and passing as parameters the tags to run the performance suite against, such as `bin/plugin/cli.js perf release/x.y release/x.z wp/a.b`. @@ -95,11 +99,9 @@ The performance values usually displayed in the release post are: - Post Editor Loading Time (test named `load`) - KeyPress Event (test named `typing`) -#### 5. Publishing the post - -Compile this to a draft post on [make.wordpress.org/core](https://make.wordpress.org/core/); this post should be published after the actual release. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)! +#### 4. Publishing the post -If you don't have access to [make.wordpress.org/core](https://make.wordpress.org/core/), ping someone on the Gutenberg Core team in the [WordPress #core-editor Slack channel](https://wordpress.slack.com/messages/C02QB2JS7) to publish the post. +Once the post content is ready, a new draft on [make.wordpress.org/core](https://make.wordpress.org/core/) needs to be created; this post should be published after the actual release. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)! ### Creating Release Candidate Patches (done via `git cherry-pick`) From e3e2ab378b89f08a38b6be53ac4fa9c0d4949d42 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 13:11:36 +0200 Subject: [PATCH 2/9] Fix typos and formatting. --- docs/contributors/code/release.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index 03bd2b8af737e2..3c9235f7760ab7 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -51,7 +51,7 @@ Once released, all that's left to do is writing a release post on [make.wordpres ### Documenting the release with the Release Notes and Post
-Documenting the release is a collaborative effort between the release manager, Gutenberg core team developers, and designers, comprised of a series of sequential steps. Because of the amount of people involved and the coordination required, this process needs to adhere to a timeline between the RC and stable releases. +Documenting the release **is a group effort between the release manager, Gutenberg core team developers, and designers** , comprised of a series of sequential steps that, because of the amount of people involved and the coordination required, need to adhere to a timeline between the RC and stable releases.
1. Curating the changelog - Wednesday after the RC release to Friday @@ -78,17 +78,17 @@ Guidelines for proof-reading include: Once the changelog is cleaned up, the next step is to choose a few changes to highlight in the release post. These highlights usually focus on new features and enhancements, including performance and accessibility ones, but can also include important API changes or critical bug fixes. -Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; because of this, this step a collaborative effort between the release manager and Gutenberg Core team members. +Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; because of this, this step is a collaborative effort between the release manager and Gutenberg Core team members. #### 3. Drafting the release post -Because of the nature of the release post content, responsibilities are divided in this step. While the post can either be written by the release manager or delegated to another core member agreed upon in advance, visual assets should be created by the design team. +Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets should be created by the design team**. When possible, the highlighted changes in the release post should include an animation (video or GIF) or a static image of them in use. Choosing between an animation or a static image will depend on the best way to showcase each highlight: while animations are better to demonstrate workflows, more direct highlights can be shown with an image; having too many video players adds a layer of friction for users to see the highlight, whereas too many simultaneous animated GIFs can distract and overwhelm the reader. These visual assets should maintain consistency with previous release posts; using lean, white themes helps in this regard and visually integrate well with the [make.wordpress.org/core](https://make.wordpress.org/core/) blog aesthetics. Including copyrighted material should be avoided, and browser plugins that can be seen in the browser canvas (spell checkers, form fillers, etc.) disabled when capturing the assets. -##### 3.3. Running the performance tests +##### 4. Running the performance tests The post should also include a performance audit at the end, comparing the current Gutenberg release with both the previous one and the latest WordPress major version. There are GitHub worfklows in place to do this comparison as part of the Continuous Integration setup, so the performance audit results can be found at the workflow run generated by the release commit in the [Performance Tests workflows](https://github.com/WordPress/gutenberg/actions/workflows/performance.yml) page, with the job name `Compare performance with current WordPress Core and previous Gutenberg versions`. @@ -99,7 +99,7 @@ The performance values usually displayed in the release post are: - Post Editor Loading Time (test named `load`) - KeyPress Event (test named `typing`) -#### 4. Publishing the post +#### 5. Publishing the post Once the post content is ready, a new draft on [make.wordpress.org/core](https://make.wordpress.org/core/) needs to be created; this post should be published after the actual release. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)! From cf22f539b9e8161566f572748273018243db81ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 13:23:35 +0200 Subject: [PATCH 3/9] Fix formatting. --- docs/contributors/code/release.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index 3c9235f7760ab7..5e1e5fa3fb64ab 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -51,7 +51,7 @@ Once released, all that's left to do is writing a release post on [make.wordpres ### Documenting the release with the Release Notes and Post
-Documenting the release **is a group effort between the release manager, Gutenberg core team developers, and designers** , comprised of a series of sequential steps that, because of the amount of people involved and the coordination required, need to adhere to a timeline between the RC and stable releases. +Documenting the release is a group effort between the release manager, Gutenberg core team developers, and designers , comprised of a series of sequential steps that, because of the amount of people involved and the coordination required, need to adhere to a timeline between the RC and stable releases.
1. Curating the changelog - Wednesday after the RC release to Friday @@ -88,7 +88,7 @@ When possible, the highlighted changes in the release post should include an ani These visual assets should maintain consistency with previous release posts; using lean, white themes helps in this regard and visually integrate well with the [make.wordpress.org/core](https://make.wordpress.org/core/) blog aesthetics. Including copyrighted material should be avoided, and browser plugins that can be seen in the browser canvas (spell checkers, form fillers, etc.) disabled when capturing the assets. -##### 4. Running the performance tests +#### 4. Running the performance tests The post should also include a performance audit at the end, comparing the current Gutenberg release with both the previous one and the latest WordPress major version. There are GitHub worfklows in place to do this comparison as part of the Continuous Integration setup, so the performance audit results can be found at the workflow run generated by the release commit in the [Performance Tests workflows](https://github.com/WordPress/gutenberg/actions/workflows/performance.yml) page, with the job name `Compare performance with current WordPress Core and previous Gutenberg versions`. From e466c4dd63cfd498c679e00c47f08d9cf1440e9a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 13:30:50 +0200 Subject: [PATCH 4/9] Rewording to avoid second person. --- docs/contributors/code/release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index 5e1e5fa3fb64ab..1fd9a733226182 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -63,7 +63,7 @@ Documenting the release is a group effort between the release manager, Gutenberg #### 1. Curating the changelog The release notes draft is auto-generated by a script that looks for pull requests for the current milestone, and groups them by pull request label. -This is intended to be a starting point for release notes; you will still want to manually review and curate the changelog entries. Because the release candidate changelog is reused in the stable release and it can be a time-consuming process, **it is recommended to start this process as soon as the milestone is closed** and the release candidate is published. +This is intended to be a starting point for release notes, and manually reviewing and curating the changelog entries is still required. The release candidate changelog is reused in the stable release and greatly helps select the highlights; because depending on the release it can be a very time-consuming process, **it is recommended to start this process as soon as the milestone is closed** and the release candidate is published. Guidelines for proof-reading include: From 330dd24fa9c341f2d453f646eea6d0a905a0a3b4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 13:34:53 +0200 Subject: [PATCH 5/9] Update release.md --- docs/contributors/code/release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index 1fd9a733226182..cae3686c0dd7e9 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -82,7 +82,7 @@ Given the big scope of Gutenberg and the high number of pull requests merged in #### 3. Drafting the release post -Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets should be created by the design team**. +Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets are best created by the design team**. When possible, the highlighted changes in the release post should include an animation (video or GIF) or a static image of them in use. Choosing between an animation or a static image will depend on the best way to showcase each highlight: while animations are better to demonstrate workflows, more direct highlights can be shown with an image; having too many video players adds a layer of friction for users to see the highlight, whereas too many simultaneous animated GIFs can distract and overwhelm the reader. From b6916ed05755805ab69b82df87ed6f650d018371 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 19:27:17 +0200 Subject: [PATCH 6/9] Add a reference to being pinged to coordinate --- docs/contributors/code/release.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index cae3686c0dd7e9..b93c8d2948774c 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -51,7 +51,7 @@ Once released, all that's left to do is writing a release post on [make.wordpres ### Documenting the release with the Release Notes and Post
-Documenting the release is a group effort between the release manager, Gutenberg core team developers, and designers , comprised of a series of sequential steps that, because of the amount of people involved and the coordination required, need to adhere to a timeline between the RC and stable releases. +Documenting the release is a group effort between the release manager, Gutenberg core team developers, and designers , comprised of a series of sequential steps that, because of the amount of people involved and the coordination required, need to adhere to a timeline between the RC and stable releases. The release manager will get pinged by a core member to kick-off and coordinate this process.
1. Curating the changelog - Wednesday after the RC release to Friday @@ -82,7 +82,7 @@ Given the big scope of Gutenberg and the high number of pull requests merged in #### 3. Drafting the release post -Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets are best created by the design team**. +Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets are created by the design team**. When possible, the highlighted changes in the release post should include an animation (video or GIF) or a static image of them in use. Choosing between an animation or a static image will depend on the best way to showcase each highlight: while animations are better to demonstrate workflows, more direct highlights can be shown with an image; having too many video players adds a layer of friction for users to see the highlight, whereas too many simultaneous animated GIFs can distract and overwhelm the reader. From cac49536d4fe475161c214be4b7f6ab5417b43f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Fri, 9 Jul 2021 19:37:27 +0200 Subject: [PATCH 7/9] Update Gutenberg membership requirements. --- docs/contributors/code/release.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index b93c8d2948774c..f4d6df74d2f0c1 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -2,7 +2,7 @@ This Repository is used to perform several types of releases. This document serves as a checklist for each one of these. It is helpful if you'd like to understand the different workflows. -To release a stable version of the Gutenberg plugin, you need approval from a member of the Gutenberg Core team for the final step of the release process (upload to the WordPress.org plugin repo -- see below). If you aren't a member yourself, make sure to contact one ahead of time so they'll be around at the time of the release. You can ping in the [#core-editor Slack channel](https://wordpress.slack.com/messages/C02QB2JS7). +To release a stable version of the Gutenberg plugin you need to be part of the [Gutenberg development team](/docs/contributors/repository-management/#teams). On top of that, you need approval from a member of the Gutenberg Core team for the final step of the release process (upload to the WordPress.org plugin repo -- see below). If you aren't a member yourself, make sure to contact one ahead of time so they'll be around at the time of the release. You can ping in the [#core-editor Slack channel](https://wordpress.slack.com/messages/C02QB2JS7). To release Gutenberg's npm packages, you need to be part of the [WordPress organization at npm](https://www.npmjs.com/org/wordpress). 🙂 @@ -78,7 +78,7 @@ Guidelines for proof-reading include: Once the changelog is cleaned up, the next step is to choose a few changes to highlight in the release post. These highlights usually focus on new features and enhancements, including performance and accessibility ones, but can also include important API changes or critical bug fixes. -Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; because of this, this step is a collaborative effort between the release manager and Gutenberg Core team members. +Given the big scope of Gutenberg and the high number of pull requests merged in each milestone, it is not uncommon to overlook impactful changes worth highlighting; because of this, this step is a collaborative effort between the release manager, design, and Gutenberg Core team members. #### 3. Drafting the release post From 93ab89617afe96ab5286d37f55f35388fdec79c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Tue, 13 Jul 2021 16:52:06 +0200 Subject: [PATCH 8/9] Fix internal handbook links --- docs/contributors/code/release.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index f4d6df74d2f0c1..2fedfdf7c23078 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -2,7 +2,7 @@ This Repository is used to perform several types of releases. This document serves as a checklist for each one of these. It is helpful if you'd like to understand the different workflows. -To release a stable version of the Gutenberg plugin you need to be part of the [Gutenberg development team](/docs/contributors/repository-management/#teams). On top of that, you need approval from a member of the Gutenberg Core team for the final step of the release process (upload to the WordPress.org plugin repo -- see below). If you aren't a member yourself, make sure to contact one ahead of time so they'll be around at the time of the release. You can ping in the [#core-editor Slack channel](https://wordpress.slack.com/messages/C02QB2JS7). +To release a stable version of the Gutenberg plugin you need to be part of the [Gutenberg development team](/docs/block-editor/contributors/repository-management/#teams). On top of that, you need approval from a member of the Gutenberg Core team for the final step of the release process (upload to the WordPress.org plugin repo -- see below). If you aren't a member yourself, make sure to contact one ahead of time so they'll be around at the time of the release. You can ping in the [#core-editor Slack channel](https://wordpress.slack.com/messages/C02QB2JS7). To release Gutenberg's npm packages, you need to be part of the [WordPress organization at npm](https://www.npmjs.com/org/wordpress). 🙂 @@ -12,7 +12,7 @@ To release Gutenberg's npm packages, you need to be part of the [WordPress organ We release a new major version approximately every two weeks. The current and next versions are [tracked in GitHub milestones](https://github.com/WordPress/gutenberg/milestones), along with each version's tagging date (the day when _the release candidate_ is to be tagged). -- **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on. [Preparation of the release post starts here](#writing-the-release-notes-and-post) and spans until the final release. +- **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on. [Preparation of the release post starts here](/docs/block-editor/contributors/code/release/#writing-the-release-notes-and-post) and spans until the final release. - **One week after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released, the release post is published, including a [performance audit](/docs/block-editor/contributors/testing-overview/#performance-testing). From 56eb56ea0609d561df4e87d68261bced8fd5b05a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9ctor?= <27339341+priethor@users.noreply.github.com> Date: Tue, 13 Jul 2021 17:17:35 +0200 Subject: [PATCH 9/9] Reword the drafting and publishing, clarify permissions to post on make/core --- docs/contributors/code/release.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contributors/code/release.md b/docs/contributors/code/release.md index 2fedfdf7c23078..cbe951cf768ced 100644 --- a/docs/contributors/code/release.md +++ b/docs/contributors/code/release.md @@ -82,7 +82,7 @@ Given the big scope of Gutenberg and the high number of pull requests merged in #### 3. Drafting the release post -Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be written by the release manager or delegated to another core member** agreed upon in advance, **visual assets are created by the design team**. +Because of the nature of the release post content, responsibilities are divided in this step. While the post **can either be drafted by the release manager or delegated to another core member** agreed upon in advance, **visual assets are created by the design team**. When possible, the highlighted changes in the release post should include an animation (video or GIF) or a static image of them in use. Choosing between an animation or a static image will depend on the best way to showcase each highlight: while animations are better to demonstrate workflows, more direct highlights can be shown with an image; having too many video players adds a layer of friction for users to see the highlight, whereas too many simultaneous animated GIFs can distract and overwhelm the reader. @@ -101,7 +101,7 @@ The performance values usually displayed in the release post are: #### 5. Publishing the post -Once the post content is ready, a new draft on [make.wordpress.org/core](https://make.wordpress.org/core/) needs to be created; this post should be published after the actual release. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)! +Once the post content is ready, an author already having permissions to post in [make.wordpress.org/core](https://make.wordpress.org/core/) will create a new draft and import the content; this post should be published after the actual release, helping external media to echo and amplify the release news. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)! ### Creating Release Candidate Patches (done via `git cherry-pick`)