[Release] 2.5.1

[felipeelia]

• 1. Branch: Starting from develop, cut a release branch named release/2.5.1 for your changes.
• 2. Version bump: Bump the version number in elasticpresslabs.php, package-lock.json, package.json, readme.txt, and any other relevant files if it does not already reflect the version being released. In elasticpresslabs.php update both the plugin "Version:" property and the plugin ELASTICPRESS_LABS_VERSION constant.
• 3. Changelog: Add/update the changelog in CHANGELOG.md and readme.txt, ensuring to link the [2.5.1] release reference in the footer of CHANGELOG.md (e.g., 2.5.0...2.5.1).
• 4. Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 5. 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.
• 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
• 7. POT file: Run wp i18n make-pot . languages/elasticpress-labs.pot and commit the file. In case of errors, try to disable Xdebug (see #3079.)
• 8. Release date: Double check the release date in both changelog files.
• 9. Merge: Merge the release branch/PR into develop, then make a non-fast-forward merge from develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• 10. Test: While still on the trunk branch, test for functionality locally.
• 11. Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
• 12. Check the Build and Tag action: a new tag named with the version number should've been created. It should contain all the built assets.
• 13. Release: Create a new release:
  • Tag: The tag created in the previous step
  • Release title: Version 2.5.1
  • Description: Release changelog from CHANGELOG.md + See: https://github.com/10up/elasticpresslabs/milestone/13?closed=1
• 14. 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.
• 15. Punt incomplete items: If any open issues or PRs which were milestoned for 2.5.1 do not make it into the release, update their milestone to 2.5.2, 2.6.0, 3.0.0 or Future Release.