Skip to content

Release Procedures

Jump to bottom
William Patton edited this page Jun 25, 2024 · 2 revisions

This document outlines the comprehensive steps involved in preparing and releasing a new version of an Accessibility Checker WordPress plugin. It includes details on a Bash script designed for version management and file updates, as well as the deployment process using GitHub Actions to the WordPress.org repository.

Prep Release Script

The script should be executed from the root directory of the repository with the following syntax:

./prep_release.sh [major|minor|patch]
  1. Script Invocation: Run the script from the root directory of your repository using ./prep_release.sh followed by the version bump type (major, minor, or patch). For example: ./prep_release.sh patch.
  2. Version Bumping: The script fetches the current plugin version from the specified main plugin file (accessibility-checker.php), then calculates and displays the bumped version.
  3. Branch Management: It creates a new release branch based on the new version number, after fetching updates from the develop branch and checking out to it.
  4. File Updates: The version number is updated in several places, including the main plugin file, package.json, and readme.txt. Backup files are created during this process and then removed when it completes.
  5. Changelog Generation: The script generates a changelog by listing pull requests merged since the last release and formats them appropriately so they can be used in a smoketest before merging.
  6. Pull Request Link: Provides a URL to open a pull request against the main branch with a pre-filled title, facilitating the release process.

Testing and Feature Verification

Before a release is finalized, comprehensive testing and verification of all new features, improvements, and bug fixes are crucial to ensure the quality and stability of the plugin. This section outlines the key steps and considerations in the testing process.

Unit Testing with PHPUnit

  • Purpose: Verify the functionality of individual units of code (functions/methods) in isolation.
  • Tools: PHPUnit, a widely used framework for unit testing PHP code.

End-to-end Testing with Playwright

  • Purpose: Simulate user interactions with the plugin in various browsers to identify any UI or functional issues.
  • Tools: Playwright, an automation library for testing web applications across modern browsers.

User Acceptance Testing (UAT)

  • Purpose: Ensure the plugin functions correctly from an end-user's perspective and meets all defined requirements.
  • Procedure:
    • The pre-release process will generate a list of all new and modified features in the plugin release.
    • Manually test these features to verify their functionality and user experience. Consider involving a group of beta testers for broader feedback.
    • Address any issues identified during UAT before proceeding with the release.

Deploy to WordPress.org Repository Workflow

Following the preparation steps, testing and merging of the release branch to main you should create a tag for the version. The release should be titled with the version number (eg v1.14.0). The tag should match the released version (being set to create the tag on publish) and be pointed at the main branch.

The deployment uses the 10up/action-wordpress-plugin-deploy action, designed for WordPress plugin deployment, requiring SVN credentials to be set as secrets in the GitHub repository.

When the tag is published it will trigger the workflow action automatically and publish the released version to the wordpress.org repository.

Conclusion

These release procedures provide a systematic approach to updating and deploying WordPress plugins, from initial preparation through to public release. By automating version management, file updates, and deployment, the process ensures efficiency and consistency in plugin releases.

Clone this wiki locally