Release: 2.0.0

[dkotter]

• Branch: Starting from develop, create a release branch named release/2.0.0 for your changes.
• Version bump: Bump the version number in distributor.php, package.json, package-lock.json, readme.txt and tests/php/bootstrap.php if it does not already reflect the version being released. In distributor.php update both the plugin "Version:" property and the plugin DT_VERSION constant.
• New files: Ensure any new files, especially in the vendor folder, are correctly included in webpack.config.release.js.
• Changelog: Add/update the changelog in CHANGELOG.md.
• Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Since tag updates: ensure @since tags indicate the new version, replacing x.x.x, n.e.x.t and other placeholders.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Build: Wait for the Build Stable Release Action to finish running.
• Review: Do a review of the commit to the stable branch to ensure the contents of the diffs are as expected.
• Test: Check out the stable branch and test it locally to ensure everything works as expected. It is recommended that you rename the existing distributor directory and check out stable fresh because switching branches does not delete files. This can be done with git clone --single-branch --branch stable [email protected]:10up/distributor.git
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the stable branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
• Check release: Wait for the Publish Release Action to complete, and then check the latest release to ensure that the ZIP has been attached as an asset. Download the ZIP and inspect the contents to be sure they match the contents of the stable branch.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 2.0.0 do not make it into the release, update their milestone to 2.0.1, 2.1.0, or Future Release.

[dkotter]

E2E tests that are running on WP 6.3 are failing due to the change in 6.3 where the Block Editor is loaded in an iframe by default. Cypress won't load the contents of the iframe by default but you can get around this with a config value (which I added here).

But in addition to that, any interaction that we do with the editor needs to account for the editor being in an iframe. For example, any use of cy.createPost will no longer work. I originally contemplated trying to fix all of that here but I think this should probably be handled in a separate PR, as well as some of these changes need to happen in our Cypress WP Utils package.

[jeffpaul]

@dkotter given the Migration guide for v1 > v2 is relatively light on need, but perhaps we should still call that out here in the CHANGELOG.md as another sentence linking to that guide for folks to reference in their upgrades? If its significant enough of a migration need, then we might also have an admin notice that references it perhaps?

[dkotter]

@dkotter given the Migration guide for v1 > v2 is relatively light on need, but perhaps we should still call that out here in the CHANGELOG.md as another sentence linking to that guide for folks to reference in their upgrades? If its significant enough of a migration need, then we might also have an admin notice that references it perhaps?

I've added links to the CHANGELOG and README files for that migration guide. I don't think it warrants an admin notice, especially since the few things we call out are more developer type things which an admin may not have the ability/access to do anything there.

[jeffpaul]

Still some other items in the v2 milestone, but nothing that I would fight people for to get into this release so approving this release PR as-is... very exciting!

[peterwilsoncc]

For the migration guide, these are possible things we should call out:

• Minimum requirements bump: WP and PHP
• REST API changes to Distributor endpoints (hopefully people are not using these)
  • different structure
  • requests from Dist < 1.x effectively blocked
• Translations now include strings in JavaScript files
• dt_push_post hook deprecated in favour of dt_push_external_post and dt_push_network_post due to parameter conflicts

[jeffpaul]

@peterwilsoncc is there an update to the hookdocs page and the changelog that you could push up here?

[jeffpaul]

@dkotter seems like we can probably bump the WP "tested up to" 6.3 here as well and set the PR to similarly close #1118, yeah?

[peterwilsoncc]

@jeffpaul @dkotter I've pushed some updates to the migration guide to cover the items listed above.

[peterwilsoncc]

@jeffpaul I think this is good to go, once Darin and I figure out some line ending differences in #1124 so composer install doesn't end up creating changes on some systems but not others.

[peterwilsoncc]

E2E tests failures are due to the iframed post editor (.block-editor-default-block-appender__content exists but not in the DOM tree Cypress has access too).

In some Gutenberg tests for the PR iframing the post editor, a dummy block was created to prevent the iframe from being initiated. Perhaps we could do that but I don't think it's a blocker for release.

[peterwilsoncc]

Reapprove following change log update.