Skip to content

Release Procedures

Jump to bottom
Steve Jones edited this page Apr 3, 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.
  5. Changelog Generation: The script generates a changelog by listing pull requests merged since the last release, excluding any release branches, and formats them appropriately.
  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, This workflow is triggered manually or upon a release event. It involves steps such as checking out the code, setting up PHP and Node.js environments, installing dependencies, building the plugin, generating release artifacts, deploying to the WordPress.org repository (with a dry-run option for testing), and optionally uploading the release asset to GitHub. 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.

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