WordPress plugin that integrates a WordPress site with the Bluehost control panel, including performance, security, and update features.
The 3.x version can be found on the main branch.
Find the bluehost-wordpress-plugin.zip asset for your preferred version at: https://github.com/bluehost/bluehost-wordpress-plugin/releases/.
Alternatively, check the updater endpoint for the latest version at: https://hiive.cloud/workers/release-api/plugins/bluehost/bluehost-wordpress-plugin, this also includes a download link to the latest zip file or use this link to access the latest download: https://hiive.cloud/workers/release-api/plugins/bluehost/bluehost-wordpress-plugin/download/.
Review the version control and releases "How We Work" docs for more information.
This plugin has version number set in 3 distinct places in 2 files:
- The plugin header info (bluehost-wordpress-plugin.php line 14) - this is used in the plugin php code.
- The constant BLUEHOST_PLUGIN_VERSION (bluehost-wordpress-plugin.php line 34) - this is used by WordPress.
- In the package.json version value (package.json line 5) this is used by the build step to place the release files within a matching version directory for convenient cache busting. All 3 instances need to be incremented in conjuction with new releases via github tagging. (There is have a validation for proper versioning in the release workflow).
The legacy 2.x version can be found on the master branch.
- Once code in the
developbranch is ready for release testing, aX.Y.Z-alpha.1version 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.
Steps to follow when releasing a new version of the plugin:
- Schedule the release with the team.
- Ensure that the
developbranch is up-to-date with the latest changes. - Create a release branch for this release:
release/X.Y.Zbranching fromdevelop. - Ensure
releasebranch has properly bumped the version.- The plugin header version.
- The plugin constant version.
- The plugin package version.
- Ensure the
releasebranch has passing tests. - Ensure the
releasebranch 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
releasebranch 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
masterbranch and be sure any changes made directly on the release branch are also merged back into thedevelopbranch. - 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.
See this figma for a style guide.
Newfold Labs is an interdisciplinary product and engineering team at Newfold Digital creating next-generation solutions that support our customers and our business. Learn more about how we work.