Update CONTRIBUTING.md

CONTRIBUTING.md

@@ -34,11 +34,12 @@ The `develop` branch is the development branch which means it contains the next
 4. Props: update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
 5. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.gitattributes`.
 6. 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.
-7. 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 trunk && git merge --no-ff develop`). `trunk` contains the stable development version.
+7. 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`, ensuring you pull the most recent changes into `develop` first (`git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version.
 8. Test: While still on the `trunk` branch, test for functionality locally.
 9. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`).
-10. Release: Create a [new release](https://github.com/10up/wp-newrelic/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [X.Y.Z milestone](https://github.com/10up/wp-newrelic/milestone/1?closed=1).
-11. SVN: Wait for the [GitHub Action](https://github.com/10up/wp-newrelic/actions) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
-12. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/wp-newrelic/. This may take a few minutes.
-13. Close milestone: Edit the [X.Y.Z milestone](https://github.com/10up/wp-newrelic/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
-14. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`.
+10. [Compare](https://github.com/10up/figma-block/compare/trunk...develop) trunk to develop to ensure no additional changes were missed.
+11. Release: Create a [new release](https://github.com/10up/wp-newrelic/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [X.Y.Z milestone](https://github.com/10up/wp-newrelic/milestone/1?closed=1).
+12. SVN: Wait for the [GitHub Action](https://github.com/10up/wp-newrelic/actions) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
+13. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/wp-newrelic/. This may take a few minutes.
+14. Close milestone: Edit the [X.Y.Z milestone](https://github.com/10up/wp-newrelic/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
+15. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`.