Bluehost WordPress Plugin

WordPress plugin that integrates your WordPress site with the Bluehost control panel, including performance, security, and update features.

Release Steps

Review the version control and releases "How We Work" docs for more information.

Pre-Releases

• Once code in the develop branch is ready for release testing, a X.Y.Z-alpha.1 version should be created and MUST be tagged as a pre-release. Subsequent alpha releases should increment the last digit of the version (e.g. X. Y.Z-alpha.2). Alpha releases are open to having new features added and/or bugs fixed. Tagging a release will trigger the full test matrix. Any test failures should be addressed.
• After all features are finalized and added to the release, a beta version should be tagged and MUST be marked as a pre-release. Beta releases are only open to having bugs fixed. Version numbers should follow the same pattern as the alpha versions (e.g. X.Y. Z-beta.1). Tagging a release will trigger the full test matrix. Any test failures should be addressed.

Production Release

Steps to follow when releasing a new version of the plugin:

• Schedule the release with the team.
• Ensure that the develop branch is up-to-date with the latest changes.
• Create a release branch for this release: release/X.Y.Z branching from develop.
• Ensure release branch has properly bumped the version.
  • The plugin header version.
  • The plugin constant version.
• Ensure the release branch has passing tests.
• Ensure the release branch passes linting.
• Tag an initial release candidate version of the plugin (e.g. X.Y.Z-rc.1) and be sure to mark it as a pre-release.
• Ensure that the release branch passes the full test matrix.
• Alert the team via chat and announce that the latest build is available for testing.
• Download the latest build and install on a site for manual testing.
• Confirm no issues are found in testing.
• If issues are found, push changes directly to the release branch, tag a new pre-release version (e.g. X.Y.Z-rc.2) and run through the manual testing process again.
• When ready to release, merge the release branch into the master branch and be sure any changes made directly on the release branch are also merged back into the develop branch.
• Create a new release tagged (X.Y.Z) and named (Version X.Y.Z) for the version. This should NOT be marked as a pre-release.
• Ensure the satis build is triggered and completes.
• Ensure that the update API displays the release as latest/current version.
• Alert the team via chat to announce the end of the release process.
• Watch for the plugin release to rollout in Hiive or monitor by running a query against the Hiive.