Update RELEASE.MD

.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

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,22 +56,147 @@ 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).
 
 2. Click the **Actions** tab.
 
 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,27 +227,26 @@ 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`).
 
 5. Under **Release notes**:
    - 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.

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(
-		'<tr class="plugin-update-tr%1$s" id="fair-error-%2$s">
-			<td colspan="%3$d" class="plugin-update colspanchange">
-				<div class="update-message notice inline notice-error notice-alt"><p>%4$s</p></div>
-			</td>
-		</tr>',
-		esc_attr( $active_class ),
-		esc_attr( sanitize_title( $plugin_file ) ),
-		esc_attr( $colspan ),
-		esc_html( $message ),
-	);
-}
-
 /**
  * Download a package with signature verification.
  *