From 4afcb7596d4f508a9bef4d0b68111dbd7737c3e7 Mon Sep 17 00:00:00 2001 From: "Ipstenu (Mika Epstein)" Date: Wed, 25 Feb 2026 15:17:08 -0800 Subject: [PATCH 1/5] Update RELEASE.MD Update release directions based on lessons from Release 1.3.0 Signed-off-by: Ipstenu (Mika Epstein) --- RELEASE.MD | 226 +++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 204 insertions(+), 22 deletions(-) diff --git a/RELEASE.MD b/RELEASE.MD index b7003c3a..dfd378b3 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-rcN` (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-rcN` (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 to merge `development` → `main` 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,46 @@ 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** -3. Check **Create a discussion for this release** and choose the **Announcements** category. +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, purse another URL +5. Put in the subdomain `api` and the path `/git-updater/v1/update-api/` -4. In a new browser tab, go to the repository’s **Actions** tab and confirm all workflows have completed. +## 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. -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. From 89208be010a523e61e777bf400fe6332c08c2fa6 Mon Sep 17 00:00:00 2001 From: Mika Ipstenu Epstein Date: Wed, 25 Feb 2026 15:26:28 -0800 Subject: [PATCH 2/5] Update .gitignore to exclude swap files and refactor updater logic to streamline package registration Signed-off-by: Mika Signed-off-by: Mika Ipstenu Epstein --- .gitignore | 1 + inc/updater/namespace.php | 82 ++------------------------------------- 2 files changed, 4 insertions(+), 79 deletions(-) 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/inc/updater/namespace.php b/inc/updater/namespace.php index a1b64aeb..361b61dc 100644 --- a/inc/updater/namespace.php +++ b/inc/updater/namespace.php @@ -73,89 +73,13 @@ function get_packages() : array { * @return void */ function run() { - if ( ! Updater::should_run_on_current_page() ) { - return; - } - $packages = get_packages(); $plugins = $packages['plugins'] ?? []; $themes = $packages['themes'] ?? []; - - foreach ( $plugins as $did => $filepath ) { - Updater::register_plugin( $did, $filepath ); - } - - foreach ( $themes as $did => $filepath ) { - Updater::register_theme( $did, $filepath ); - } - - // Load hooks once for all packages. - Updater::load_hooks(); -} - -/** - * 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; + $packages = array_merge( $plugins, $themes ); + foreach ( $packages as $did => $filepath ) { + ( new Updater( $did, $filepath ) )->run(); } - - $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 ), - ); } /** From 07f39f0639511d95e12a25b0cf97c2cfc9c186df Mon Sep 17 00:00:00 2001 From: Mika Ipstenu Epstein Date: Wed, 25 Feb 2026 15:28:01 -0800 Subject: [PATCH 3/5] Enhance updater functionality by adding package registration and error display for plugins. Introduced methods to register hooks for plugin update errors and display relevant messages in the admin interface. Signed-off-by: Mika Ipstenu Epstein --- inc/updater/namespace.php | 82 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 79 insertions(+), 3 deletions(-) diff --git a/inc/updater/namespace.php b/inc/updater/namespace.php index 361b61dc..a1b64aeb 100644 --- a/inc/updater/namespace.php +++ b/inc/updater/namespace.php @@ -73,13 +73,89 @@ function get_packages() : array { * @return void */ function run() { + if ( ! Updater::should_run_on_current_page() ) { + return; + } + $packages = get_packages(); $plugins = $packages['plugins'] ?? []; $themes = $packages['themes'] ?? []; - $packages = array_merge( $plugins, $themes ); - foreach ( $packages as $did => $filepath ) { - ( new Updater( $did, $filepath ) )->run(); + + foreach ( $plugins as $did => $filepath ) { + Updater::register_plugin( $did, $filepath ); + } + + foreach ( $themes as $did => $filepath ) { + Updater::register_theme( $did, $filepath ); + } + + // Load hooks once for all packages. + Updater::load_hooks(); +} + +/** + * 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 ), + ); } /** From d93674fbb48e71d9242eb31f504de7edd583c0b0 Mon Sep 17 00:00:00 2001 From: Mika Ipstenu Epstein Date: Wed, 25 Feb 2026 15:30:25 -0800 Subject: [PATCH 4/5] Github decided duplicating methods was a smart thing? Signed-off-by: Mika Epstein Signed-off-by: Mika Ipstenu Epstein --- inc/updater/namespace.php | 65 --------------------------------------- 1 file changed, 65 deletions(-) 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. * From 5614c291472bb10da430e1843d3c590cf0ee3e46 Mon Sep 17 00:00:00 2001 From: Mika Ipstenu Epstein Date: Thu, 12 Mar 2026 09:28:26 -0700 Subject: [PATCH 5/5] Update RELEASE.MD to standardize version format for release candidates from `-rcN` to `-RC#` and clarify release process steps. Added instructions for merging production code back into development. Signed-off-by: Mika Ipstenu Epstein --- RELEASE.MD | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/RELEASE.MD b/RELEASE.MD index dfd378b3..1cd424ec 100644 --- a/RELEASE.MD +++ b/RELEASE.MD @@ -30,7 +30,7 @@ A production release represents a stable, tested version ready for general use. ### 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-rcN` (e.g., `1.2.0-rc1`, `1.2.0-rc2`) +- **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 @@ -77,7 +77,7 @@ Follow these steps to release an RC from the `release/X.Y.Z` branch. Multiple RC 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-rcN` (e.g., `1.2.0-rc1`, `1.2.0-rc2`) + - **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. @@ -124,11 +124,11 @@ The `release/X.Y.Z` branch must be merged to `development` for testing and valid 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`). + - 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`). +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). @@ -157,10 +157,10 @@ The `release/X.Y.Z` branch must be merged to `development` for testing and valid ### 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`) +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 to merge `development` → `main` for the final release. +Proceed to the **Production Release** workflow below for the final release. --- @@ -295,14 +295,19 @@ Flush the caches in the following order: 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, purse another URL +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 +- 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. +## 10. Merge the new production code back + +- Merge `main` back into `development` +- Create a new branch for the next release off of `main` + Guess what? You're done! Make a post on the website and cheer.