Releasing to wp.org

Before you release you should ensure you've properly tested the plugin.

• Unit Tests Run.
• You've verified the functionality of the plugin locally.
• You've verified the functionality of the plugin on any hosted sites you have access to.
• Things to test: activation/deactivation, uninstall, access admin, run a backup, upgrade.

Release

• Before a release run npm update and composer update, so that all packages are up to date.

• If there are composer updates you'll need to commit the updated composer.lock file back to GitHub.

• Run grunt build.

  To see which tasks this runs, look in grunt/aliases.yml, basically, it makes sure CSS is prefixed and minified, as well as the JS, then it ups the version number in all files which reference the plugin version number. then it refreshes the translatable strings.

  The bumpup task can take an argument: patch|minor|major - by default, it’s patch so it will update the last digit. To release a minor of major, you’ll need to run the individual tasks that are part of the build task manually and call grunt bumpup:minor where you would run grunt bumpup - there’s obviously an opportunity for improvement here.

• After checking that version numbers were bumped up correctly, it’s time to prepare the changelog.

  You can use the git log as a starting point, run something like git log X.X.X..HEAD --no-merges --oneline > changelog.txt where X.X.X is the last release tag

  _However, you should always handcraft the changelog, a list of git commit messages is not enough.

• You can also write an upgrade notice if deemed useful

• The changelog should be added to readme/readme-footer.txt

• run grunt concat to update the readme.txt file in the /bin folder

• Commit to git

• Tag the release: git tag -a x.x.x -m "version x.x.x" , git push --tags

• run svn list https://plugins.svn.wordpress.org to accept the certificate ( one time only )

• run grunt release

This will copy the necessary plugin files to releases/svn/trunk, you’ll then need to manually create a tag folder in svn/tags for the new version ( another opportunity for automating)

It will also create a zip file that you can use to quickly test it works on a test site

Then either using the svn CLI or Cornerstone, you need to svn commit the tag folder and the trunk folder, after adding all the new files/changes.

Instructions for working with SVN and the plugin repo can be found here: https://en-gb.wordpress.org/plugins/about/svn/