diff --git a/.gitignore b/.gitignore index d30c9112..ba3e0534 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ phpcs.xml /tests/phpunit/cache /tests/phpunit/coverage wp-tests-config.php +*.swp # Track placeholders so that empty directories stay in the repo. !.gitkeep diff --git a/RELEASE.MD b/RELEASE.MD index b7003c3a..1cd424ec 100644 --- a/RELEASE.MD +++ b/RELEASE.MD @@ -1,17 +1,49 @@ # Releasing a new version of FAIR Connect ## 0. Ensure adequate permissions -To perform a release of FAIR Connect, you need the following: +To perform a release of FAIR Connect, the Release Manager needs the following: - `write` or higher permissions on the [FAIR Connect repository](https://github.com/fairpm/fair-plugin) -- `maintain` or higher permissions on the [TSC repository](https://github.com/fairpm/tsc) (this is required to post a Discussion in the Announcements category per step 7.3.) +- `maintain` or higher permissions on the [TSC repository](https://github.com/fairpm/tsc) (this is required to post a Discussion in the Announcements category per step 9.3.) -## 1. Verify milestone readiness +## 1. Branching strategy overview + +FAIR Connect follows a gated release branching strategy to ensure quality and control. For the complete strategy and automation details, see [Release Branching Strategy](https://github.com/fairpm/tsc/blob/main/process/release-branching.md). + +### Release branch lifecycle: +1. A `release/X.Y.Z` branch is created from `main` before the release process begins +2. All version bumps and fixes for this release happen on the `release/X.Y.Z` branch +3. The release manager merges `release/X.Y.Z` → `development` for testing and RC validation +4. Once validated, the release manager merges `release/X.Y.Z` → `main` for the production release + +This document assumes the `release/X.Y.Z` branch already exists. + +## 2. Release types and versioning + +FAIR Connect supports two types of releases, each with distinct workflows and version naming conventions: + +### Production Release +A production release represents a stable, tested version ready for general use. +- **Version format:** `MAJOR.MINOR.PATCH` (e.g., `1.2.0`) +- **Merge target:** `main` branch +- **GitHub release:** Marked as the latest release +- **Announcement:** Posted to Announcements discussion + +### Release Candidate (RC) +A release candidate is a pre-release version intended for testing and validation before the final production release. Multiple RCs may be created and tested before the final release. +- **Version format:** `MAJOR.MINOR.PATCH-RC#` (e.g., `1.2.0-RC1`, `1.2.0-RC2`) +- **Merge target:** `development` branch +- **GitHub release:** Marked as a pre-release (not the latest release) +- **Announcement:** Typically not announced to production users; may be shared in Discussions for testing feedback + +Use the appropriate workflow below based on which release type you are performing. + +## 3. Verify milestone readiness Before starting the release process, ensure that the milestone for the upcoming release is finalized and clear. 1. Go to the FAIR Connect [**Milestones**](https://github.com/fairpm/fair-plugin/milestones) page. - You can also access this from the repository’s main page by clicking **Issues** or **Pull requests**, then **Milestones**. + You can also access this from the repository's main page by clicking **Issues** or **Pull requests**, then **Milestones**. 2. Open the milestone corresponding to the version being released. 3. Review all issues and pull requests assigned to the milestone. @@ -24,7 +56,13 @@ Before starting the release process, ensure that the milestone for the upcoming Once the milestone contains no open issues or pull requests, the release is ready to proceed. -## 2. Start the release workflow +--- + +# Releasing a Release Candidate (RC) + +Follow these steps to release an RC from the `release/X.Y.Z` branch. Multiple RCs may be created and tested before moving to the production release. + +## 1. Start the release workflow 1. Go to the FAIR Connect [repository](https://github.com/fairpm/fair-plugin/actions). @@ -32,14 +70,133 @@ Once the milestone contains no open issues or pull requests, the release is read 3. In the *Actions* workflow list, select **Bump version for release**. +## 2. Configure and run the workflow + +1. Click the **Run workflow** button. A workflow input panel opens. + +2. Complete the following fields: + + - **Use workflow from:** Select **Branch: release/X.Y.Z** + - **New version being released:** Enter the RC version using the format `X.Y.Z-RC#` (e.g., `1.2.0-RC1`, `1.2.0-RC2`) + +3. Click the **Run workflow** button to start the release process. + +4. Refresh the page to view workflow progress. + +5. Click the running workflow to open the logs. + +6. When the workflow finishes, it creates a pull request containing the version-bump changes. + +## 3. Review and merge the version bump PR + +1. Go to the **Pull requests** tab. + +2. Open the version-bump pull request created by the release workflow. + +3. Review the changes: + + - Update of the version number in `plugin.php` + - Update the `VERSION` constant in `plugin.php` + +4. Confirm that the changes are correct. + +5. After review and approval, merge the PR to the `release/X.Y.Z` branch. + +6. Go to the **Actions** tab to verify that workflow processing is complete. + +7. Continue to the next step once all workflows finish. + +## 4. Merge release branch to development + +The `release/X.Y.Z` branch must be merged to `development` for testing and validation. + +1. In the repository, create a pull request to merge `release/X.Y.Z` → `development` +2. For the PR title, use: `release: merge release/X.Y.Z into development for RC testing` +3. Ensure all checks pass and obtain required reviews per branch protection rules +4. Merge the PR to `development` + +**BE AWARE!** The release branch may be auto-deleted. If so, _BEFORE_ you close the window, click **RESTORE BRANCH** + +## 5. Create a new release on GitHub + +1. From the repository's main page, click the **Releases** link — or go directly to the [Releases page](https://github.com/fairpm/fair-plugin/releases). + +2. Click the **Draft a new release** button. + +3. In the **Select tag** field: + - Select the tag that matches the version you just bumped to (e.g., `1.2.0-RC1`). + - Create a new tag if it does not appear in the dropdown. + - **Target branch:** Select `development` + +4. In the **Release title** field, enter a title for the release (e.g., `1.2.0-RC1`). + +5. Under **Release notes**: + - Leave the **Describe this release** field empty or add minimal testing instructions (release notes will be generated when the final production release is created). + - Check **Set as a pre-release** to mark this as a release candidate. + +6. Click the **Save draft** button. + +## 6. Finalize and publish the release + +1. Return to the **Draft Release** page, if not already there. + +2. Release-specific settings: + - Do NOT check **Set as the latest release** (already marked as pre-release from step 5). + - Optionally check **Create a discussion for this release** if you want to notify testers; if checked, you may choose a different category (e.g., General) instead of Announcements. + +3. In a new browser tab, go to the repository's **Actions** tab and confirm all workflows have completed. + +4. Return to the **Draft Release** page and click **Publish release**. This initiates the remaining release workflows. + +5. Verify the release: + - Visit the [Releases page](https://github.com/fairpm/fair-plugin/releases) to confirm RC is tagged as pre-release. + - Notify relevant testers to validate the RC version. + +## 7. Next steps + +### If additional testing iterations are needed: +1. Continue making fixes on the `release/X.Y.Z` branch +2. Merge fixes back to `development` +3. Repeat steps 2-6 for the next RC (e.g., `1.2.0-RC2`) + +### If the RC is validated and ready for production: +Proceed to the **Production Release** workflow below for the final release. + +--- + +# Releasing a Production Release + +Follow these steps to release the production version from `main` after the RC(s) have been validated. + +## 1. Start the release workflow + +1. Go to the FAIR Connect [repository](https://github.com/fairpm/fair-plugin/actions). + +2. Click the **Actions** tab. + +3. In the *Actions* workflow list, select **Bump version for release**. + +## 2. Merge release branch into main + +The `release/X.Y.Z` branch contains all the code and must be merged to `main` for the production release. + +1. In the repository, create a pull request to merge `release/X.Y.Z` → `main` +2. For the PR title, use: `release: merge release/X.Y.Z into main for production release` +3. Ensure all checks pass and obtain required reviews per branch protection rules +4. Merge the PR to `main` + +Once all workflows are complete, move on to the next step. + +Note: At this stage you _can_ delete the release branch. + ## 3. Configure and run the workflow 1. Click the **Run workflow** button. A workflow input panel opens. 2. Complete the following fields: - - **Use workflow from:** Select **Branch: main** (default). - - **New version being released:** Enter the release version number (e.g., `1.0.0`). FAIR Connect uses semantic versioning (`MAJOR.MINOR.PATCH`). + - **Use workflow from:** Select **Branch: `main`** + - **New version being released:** Enter the production version using semantic versioning format (e.g., `1.2.0`) 3. Click the **Run workflow** button to start the release process. @@ -70,13 +227,14 @@ Once the milestone contains no open issues or pull requests, the release is read ## 5. Create a new release on GitHub -1. From the repository’s main page, click the **Releases** link — or go directly to the [Releases page](https://github.com/fairpm/fair-plugin/releases). +1. From the repository's main page, click the **Releases** link — or go directly to the [Releases page](https://github.com/fairpm/fair-plugin/releases). 2. Click the **Draft a new release** button. 3. In the **Select tag** field: - Select the tag that matches the version you just bumped to (e.g., `1.2.0`). - Create a new tag if it does not appear in the dropdown. + - **Target branch:** Select `main` 4. In the **Release title** field, enter a title for the release (e.g., `1.2.0`). @@ -84,13 +242,11 @@ Once the milestone contains no open issues or pull requests, the release is read - Leave **Previous tag** set to `Auto`. - Click **Generate release notes**. - Review and edit the generated notes as needed. - - Click the **Save draft** button. + - You can add additional information directly in the **Describe this release** field if needed. If a teammate is preparing a release post for FAIR.pm, coordinate with them to include any relevant details. -> [!TIP] -> You can add additional information directly in the **Describe this release** field. -> If a teammate is preparing a release post for FAIR.pm, coordinate with them to include any relevant details. +6. Click the **Save draft** button. -## 6. Update the changelog before publishing the GitHub release +## 6. Update the changelog 1. In a new browser tab, open [`CHANGELOG.md`](/CHANGELOG.md). @@ -107,20 +263,51 @@ Once the milestone contains no open issues or pull requests, the release is read 6. Review, approve, and merge the pull request. - ## 7. Finalize and publish the release 1. Return to the **Draft Release** page. -2. Check **Set as the latest release**. +2. Release-specific settings: + - Check **Set as the latest release**. + - Check **Create a discussion for this release** and choose the **Announcements** category. + +3. In a new browser tab, go to the repository's **Actions** tab and confirm all workflows have completed. + +4. Return to the **Draft Release** page and click **Publish release**. This initiates the remaining release workflows. + +## 8. Flush Caches + +Flush the caches in the following order: + +**Redis** + +1. Log in to AWS Console for Site Cache: https://us-east-1.console.aws.amazon.com/elasticache/home?region=us-east-1#/valkey/site-cache +2. Scroll down and click on **Connect to Cache** +3. When the page has loaded, type `flushall` + +**Git Updater** + +1. Log in to the network admin page for GitUpdater: https://fair.pm/wp-admin/network/settings.php?page=git-updater +2. Press the **Clear Cache** button + +**Fastly** + +1. Log in to Fastly and go to the Fair.pm page: https://manage.fastly.com/configure/services/0EAkUOqF5q35zrk6oobCP4 +2. From the Purge menu option, select **Purge URL** +3. Leave subdomain blank and put in the path `/wp-json/git-updater/v1/update-api/` +4. When prompted, purge another URL +5. Put in the subdomain `api` and the path `/git-updater/v1/update-api/` + +## 9. Verify the release: +- Visit the [Releases page](https://github.com/fairpm/fair-plugin/releases) to confirm latest release. +- Go to `https://api.fair.pm/git-updater/v1/update-api/?slug=fair-plugin` and check +- Check any site using FAIR Connect to ensure the new version is available. -3. Check **Create a discussion for this release** and choose the **Announcements** category. +## 10. Merge the new production code back -4. In a new browser tab, go to the repository’s **Actions** tab and confirm all workflows have completed. +- Merge `main` back into `development` +- Create a new branch for the next release off of `main` -5. Return to the **Draft Release** page and click **Publish release**. This initiates the remaining release workflows. +Guess what? -6. Verify the release: - - Visit the [Releases page](https://github.com/fairpm/fair-plugin/releases) to confirm latest release. - - Check any site using FAIR Connect to ensure the new version is available. - - Verify the updated version number in the API response. (Example URL to check: https://api.fair.pm/git-updater/v1/update-api/?slug=fair-plugin) +You're done! Make a post on the website and cheer. diff --git a/inc/updater/namespace.php b/inc/updater/namespace.php index a1b64aeb..ede4e357 100644 --- a/inc/updater/namespace.php +++ b/inc/updater/namespace.php @@ -158,71 +158,6 @@ function display_plugin_update_error( $plugin_file, $plugin_data, $status, $did ); } -/** - * Register hooks to display update errors below plugin rows. - */ -function register_plugin_row_hooks(): void { - $packages = get_packages(); - $plugins = $packages['plugins'] ?? []; - - foreach ( $plugins as $did => $path ) { - $plugin_file = plugin_basename( $path ); - add_action( - "after_plugin_row_{$plugin_file}", - function ( $file, $plugin_data, $status ) use ( $did ) { - display_plugin_update_error( $file, $plugin_data, $status, $did ); - }, - 10, - 3 - ); - } -} - -/** - * Display a cached update error below the plugin row. - * - * @param string $plugin_file Path to the plugin file relative to the plugins directory. - * @param array $plugin_data An array of plugin data. - * @param string $status Status filter currently applied to the plugin list. - * @param string $did The DID of the plugin. - */ -function display_plugin_update_error( $plugin_file, $plugin_data, $status, $did ): void { - $error = get_site_transient( CACHE_UPDATE_ERRORS . $did ); - if ( ! is_wp_error( $error ) ) { - return; - } - - $wp_list_table = _get_list_table( 'WP_Plugins_List_Table' ); - $colspan = $wp_list_table->get_column_count(); - - // Calculate time remaining until retry. - $error_data = $error->get_error_data(); - $timestamp = $error_data['timestamp'] ?? 0; - $retry_time = $timestamp + CACHE_LIFETIME_FAILURE; - $time_remaining = human_time_diff( time(), $retry_time ); - - $message = sprintf( - /* translators: %1$s: Error message, %2$s: Time period */ - __( 'Error: %1$s. Update checks paused for %2$s.', 'fair' ), - $error->get_error_message(), - $time_remaining, - ); - - $active_class = is_plugin_active( $plugin_file ) ? ' active' : ''; - - printf( - ' - -

%4$s

- - ', - esc_attr( $active_class ), - esc_attr( sanitize_title( $plugin_file ) ), - esc_attr( $colspan ), - esc_html( $message ), - ); -} - /** * Download a package with signature verification. *