prepare 12/9 build

.github/CODEOWNERS

@@ -101,9 +101,9 @@
 /packages/plugins                               @gziolo @adamsilverstein
 
 # Rich Text
-/packages/format-library                        @ellatrix @etoledom @cameronvoell @guarani
-/packages/rich-text                             @ellatrix @etoledom @cameronvoell @guarani
-/packages/block-editor/src/components/rich-text @ellatrix @etoledom @cameronvoell @guarani
+/packages/format-library                        @ellatrix @cameronvoell @guarani
+/packages/rich-text                             @ellatrix @cameronvoell @guarani
+/packages/block-editor/src/components/rich-text @ellatrix @cameronvoell @guarani
 
 # Project Management
 /.github                                        @mapk @karmatosed

.github/workflows/end2end-test.yml

@@ -16,6 +16,7 @@ jobs:
     runs-on: ubuntu-latest
 
     strategy:
+      fail-fast: false
       matrix:
         part: [1, 2, 3, 4]
 

.github/workflows/unit-test.yml

@@ -47,6 +47,55 @@ jobs:
     - name: Running the tests
       run: npm run test-unit -- --ci --maxWorkers=2 --cacheDirectory="$HOME/.jest-cache"
 
+  unit-js-date:
+    name: JavaScript / Date functions
+
+    runs-on: ubuntu-latest
+
+    strategy:
+      fail-fast: false
+      matrix:
+        timezone: ['EST', 'GMT', 'CET']
+        locale: ['en_US', 'ja_JP']
+
+    steps:
+    - uses: actions/checkout@v2
+
+    - name: Cache node modules
+      uses: actions/cache@v2
+      env:
+        cache-name: cache-node-modules
+      with:
+        # npm cache files are stored in `~/.npm` on Linux/macOS
+        path: ~/.npm
+        key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
+        restore-keys: |
+          ${{ runner.os }}-build-${{ env.cache-name }}-
+          ${{ runner.os }}-build-
+          ${{ runner.os }}-
+
+    - name: Use Node.js 14.x
+      uses: actions/setup-node@v1
+      with:
+        node-version: 14.x
+
+    - name: Npm install and build
+      # It's not necessary to run the full build, since Jest can interpret
+      # source files with `babel-jest`. Some packages have their own custom
+      # build tasks, however. These must be run.
+      run: |
+        npm ci
+        npx lerna run build
+
+    - name: Running the tests
+      env:
+        TZ: ${{ matrix.timezone }}
+        LANG: ${{ matrix.locale }}
+
+      run: |
+        npm run test-unit -- --ci --maxWorkers=2 --cacheDirectory="$HOME/.jest-cache" \
+          --testPathPattern="packages/date/"
+
   unit-php:
     name: PHP
 

.vscode/launch.json

@@ -0,0 +1,14 @@
+{
+	"version": "0.2.0",
+	"configurations": [
+		{
+			"name": "Listen for Xdebug",
+			"type": "php",
+			"request": "launch",
+			"port": 9003,
+			"pathMappings": {
+				"/var/www/html/wp-content/plugins/gutenberg": "${workspaceRoot}/"
+			}
+		}
+	]
+}

bin/plugin/commands/packages.js

@@ -6,6 +6,7 @@ const glob = require( 'fast-glob' );
 const fs = require( 'fs' );
 const semver = require( 'semver' );
 const readline = require( 'readline' );
+const { prompt } = require( 'inquirer' );
 
 /**
  * Internal dependencies
@@ -20,6 +21,12 @@ const {
 } = require( './common' );
 const git = require( '../lib/git' );
 
+/**
+ * Semantic Versioning labels.
+ *
+ * @typedef {('major'|'minor'|'patch')} SemVer
+ */
+
 /**
  * Checks out the WordPress release branch and syncs it with the changes from
  * the last plugin release.
@@ -88,7 +95,7 @@ async function runWordPressReleaseBranchSyncStep(
  * contain new entries.
  *
  * @param {string} gitWorkingDirectoryPath Git working directory path.
- * @param {string} minimumVersionBump      Minimum version bump for the packages.
+ * @param {SemVer} minimumVersionBump      Minimum version bump for the packages.
  * @param {boolean} isPrerelease           Whether the package version to publish is a prerelease.
  * @param {string} abortMessage            Abort Message.
  */
@@ -238,12 +245,11 @@ async function runPushGitChangesStep(
 /**
  * Prepare everything to publish WordPress packages to npm.
  *
- * @param {string} minimumVersionBump Minimum version bump for the packages.
- * @param {boolean} isPrerelease Whether the package version to publish is a prerelease.
+ * @param {boolean} [isPrerelease] Whether the package version to publish is a prerelease.
  *
  * @return {Promise<Object>} Github release object.
  */
-async function prepareForPackageRelease( minimumVersionBump, isPrerelease ) {
+async function prepareForPackageRelease( isPrerelease ) {
 	// This is a variable that contains the abort message shown when the script is aborted.
 	let abortMessage = 'Aborting!';
 	const temporaryFolders = [];
@@ -261,6 +267,16 @@ async function prepareForPackageRelease( minimumVersionBump, isPrerelease ) {
 		abortMessage
 	);
 
+	const { minimumVersionBump } = await prompt( [
+		{
+			type: 'list',
+			name: 'minimumVersionBump',
+			message: 'Select the minimum version bump for packages:',
+			default: 'patch',
+			choices: [ 'patch', 'minor', 'major' ],
+		},
+	] );
+
 	await updatePackages(
 		gitWorkingDirectoryPath,
 		minimumVersionBump,
@@ -280,6 +296,9 @@ async function prepareForPackageRelease( minimumVersionBump, isPrerelease ) {
 	await runCleanLocalFoldersStep( temporaryFolders, abortMessage );
 }
 
+/**
+ * Prepares everything for publishing a new stable version of WordPress packages.
+ */
 async function prepareLatestDistTag() {
 	log(
 		formats.title(
@@ -289,7 +308,7 @@ async function prepareLatestDistTag() {
 		"To perform a release you'll have to be a member of the WordPress Team on npm.\n"
 	);
 
-	await prepareForPackageRelease( 'patch' );
+	await prepareForPackageRelease();
 
 	log(
 		'\n>> 🎉 WordPress packages are ready to publish!\n',
@@ -298,6 +317,9 @@ async function prepareLatestDistTag() {
 	);
 }
 
+/**
+ * Prepares everything for publishing a new RC version of WordPress packages.
+ */
 async function prepareNextDistTag() {
 	log(
 		formats.title(
@@ -307,7 +329,7 @@ async function prepareNextDistTag() {
 		"To perform a release you'll have to be a member of the WordPress Team on npm.\n"
 	);
 
-	await prepareForPackageRelease( 'minor', true );
+	await prepareForPackageRelease( true );
 
 	log(
 		'\n>> 🎉 WordPress packages are ready to publish!\n',

changelog.txt

@@ -1,5 +1,14 @@
 == Changelog ==
 
+= 9.5.1 =
+
+### Bug Fixes:
+
+ - Revert date changes from branch 'replace-moment.
+ - Popover: Fix issue with undefined getBoundingClientRect.
+ - Fallback to regular subscribe if the store doesn't exist in useSelect.
+
+
 = 9.5.0 =
 
 ### Features
@@ -6369,7 +6378,7 @@ Add knobs to the [ColorIndicator Story](https://github.com/WordPress/gutenberg/p
 * `is_gutenberg_page` incorrectly assumes `get_current_screen` exists, add check.
 * Brings code inline with CSS standards by switching font weight to numeric values.
 * Wrapped component would not the most up-to-date store values if it incurred a store state change during its own mount (e.g. dispatching during its own constructor), resolved by rerunning selection.
-* Display an error message if Javascript is disabled.
+* Display an error message if JavaScript is disabled.
 * Update to React 16.6.3.
 * Adds missing components dependency for RichText.
 * Refactors list block to remove previously exposed RichText/TinyMCE logic.

docs/contributors/release.md

@@ -233,7 +233,7 @@ If you don't have access to [make.wordpress.org/core](https://make.wordpress.org
 The Gutenberg repository mirrors the [WordPress SVN repository](https://make.wordpress.org/core/handbook/about/release-cycle/) in terms of branching for each SVN branch, a corresponding Gutenberg `wp/*` branch is created:
 
 - The `wp/trunk` branch contains all the packages that are published and used in the `trunk` branch of WordPress.
-- A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the WordPress `trunk` branch is marked as "feature-freezed". (This usually happens when the first `beta` of the next WordPress major version is released).
+- A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the corresponding WordPress release branch is created. (This usually happens when the first `RC` of the next WordPress major version is released). 
 
 ### Synchronizing WordPress Trunk
 
@@ -249,7 +249,7 @@ The first step is automated via `./bin/plugin/cli.js npm-stable` command. You on
 4. Remove all files from the current branch: `git rm -r .`.
 5. Check out all the files from the release branch: `git checkout release/x.x -- .`.
 6. Commit all changes to the `wp/trunk` branch with `git commit -m "Merge changes published in the Gutenberg plugin vX.X release"` and push to the repository.
-7. Update the `CHANGELOG.md` files of the packages with the new publish version calculated and commit to the `wp/trunk` branch. Assuming the package versions are written using this format `major.minor.patch`, make sure to bump at least the `minor` version number. For example, if the CHANGELOG of the package to be released indicates that the next unreleased version is `5.6.1`, choose `5.7.0` as a version in case of `minor` version.
+7. Update the `CHANGELOG.md` files of the packages with the new publish version calculated and commit to the `wp/trunk` branch. Assuming the package versions are written using this format `major.minor.patch`, make sure to bump at least the `minor` version number. For example, if the CHANGELOG of the package to be released indicates that the next unreleased version is `5.6.1`, choose `5.7.0` as a version in case of `minor` version. This is important as the patch version numbers should be reserved in case bug fixes are needed for a minor WordPress release (see below).
 
 Once the command is finished, you can start the second part: publishing the npm packages.
 
@@ -270,15 +270,16 @@ The following workflow is needed when bug fixes or security releases need to be
 - During the `beta` and the `RC` period of the WordPress release cycle.
 - For WordPress minor releases and WordPress security releases (example `5.1.1`).
 
-1. Cherry-pick
-2. Check out the last published Gutenberg release branch `git checkout release/x.x`
-3. Create a Pull Request from this branch targeting the WordPress related major branch (Example `wp/5.2`).
+1. Check out the relevant WordPress major branch (If the minor release is 5.2.1, check out `wp/5.2`).
+2. Create a feature branch from that branch, and cherry-pick the merge commits for the needed bug fixes onto it.
+3. Create a Pull Request from this branch targeting the WordPress major branch used above.
 4. Merge the Pull Request using the "Rebase and Merge" button to keep the history of the commits.
 
 Now, the branch is ready to be used to publish the npm packages.
 
 1. Check out the WordPress branch used before (Example `wp/5.2`).
-2. Run the [package release process] but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version.
+2. `git pull`.
+3. Run the [package release process] but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version.
 
 **Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targeting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version.
 
@@ -311,7 +312,7 @@ Now _cherry-pick_ the commits from `master` to `wp/trunk`, use `-m 1 commithash`
 1. `git cherry-pick -m 1 cb150a2`
 2. `git push`
 
-Whilst waiting for the Travis CI build for  `wp/trunk` [branch to pass](https://travis-ci.com/WordPress/gutenberg/branches) identify and begin updating the `CHANGELOG.md` files:
+Whilst waiting for the GitHub actions build for `wp/trunk`[branch to pass](https://github.com/WordPress/gutenberg/actions?query=branch%3Awp%2Ftrunk), identify and begin updating the `CHANGELOG.md` files:
 1. `git checkout wp/trunk`
 2. `npm run publish:check`
 > Example