Release 3.0.1

[rebeccahum]

trafficstars

:warning: DO NOT MERGE (YET) :warning:

Remaining work for this Milestone

PR for tracking changes for the X.Y.Z release. Target release date: DOW DD MMMM YYYY.

• [ ] Scan WordPress (or just wp-admin folder) with prior version and compare results against new release for potential new bugs.
• [ ] Add change log for this release: PR #XXX
• [ ] Double-check whether any dependencies need bumping.
• [ ] Merge this PR.
• [ ] Add signed release tag against main.
• [ ] Close the current milestone.
• [ ] Open a new milestone for the next release.
• [ ] If any open PRs/issues which were milestoned for this release do not make it into the release, update their milestone.
• [ ] Write a Lobby post.
• [ ] Write an internal P2 post.
• [ ] Open PR to update Review Bot dependencies.

[jrfnl]

@rebeccahum If I look at the git graph, this branch looks wrong. Looks like everything has been cherrypicked from develop into a release branch.

If I look at the graph for previous releases, there have been one of two different workflows which look to have been followed:

1. pull changelog to develop and merge develop to main via a PR, then tag the main branch to release.
2. create a release branch based on develop which includes the changelog commit and pulled that branch to main, merge & tag main and once the release is out, main (or the release branch) should be merged to develop to get the changelog up to date in the develop branch.

The first workflow seems simplest to me.

Was there any particular reason not to do it that way this time ? Maybe time to document the release process properly and add a release-checklist.md file to the .github folder ? (unofficial convention)

[rebeccahum]

Okay, I'll re-make this PR then.