From b5a5a8dbc438e8b77db1e8ac6d423498555f7c6a Mon Sep 17 00:00:00 2001 From: Mehul Gohil Date: Mon, 15 Jun 2026 18:17:00 +0530 Subject: [PATCH 1/2] docs: refresh AGENTS branch guidance --- AGENTS.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 3e56681..e4f6034 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -4,13 +4,17 @@ Guidance for AI coding agents working on the Perform WordPress plugin. ## Project Snapshot - Plugin: `Perform` -- Current public line: `1.5.1` -- Active release branch in this workspace: `release/1.6.0` - Stack: - PHP (WordPress plugin, PSR-4 autoload `Perform\\` -> `src/`) - JS/CSS via `@wordpress/scripts` + webpack output in `assets/dist` - Freemius SDK via Composer +## Branch And Release Workflow +- `develop` is the default integration branch for workflow-policy and documentation changes unless current release evidence proves a different base. +- Release-scoped work uses `release/` branches. Verify the live branch list each run instead of hardcoding a single active release branch here. +- If an issue or milestone maps to an existing `release/` branch, create the work branch from that release branch and set the PR base explicitly. +- Verify the current public version and release line from live repo metadata such as `readme.txt`, GitHub releases, and WordPress.org signals rather than relying on a static value in this file. + ## Non-Negotiable Compatibility Rules - Do not rename existing option/meta keys used by released versions. - Preserve backward compatibility with legacy settings sections: From c33669e9b67171109341a5a9abc25e1b02e85e1d Mon Sep 17 00:00:00 2001 From: Mehul Gohil Date: Tue, 16 Jun 2026 18:07:41 +0530 Subject: [PATCH 2/2] docs: add Perform release cadence guidance --- AGENTS.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index e4f6034..94c2920 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -14,6 +14,9 @@ Guidance for AI coding agents working on the Perform WordPress plugin. - Release-scoped work uses `release/` branches. Verify the live branch list each run instead of hardcoding a single active release branch here. - If an issue or milestone maps to an existing `release/` branch, create the work branch from that release branch and set the PR base explicitly. - Verify the current public version and release line from live repo metadata such as `readme.txt`, GitHub releases, and WordPress.org signals rather than relying on a static value in this file. +- Release-readiness checks are project-specific: evaluate minor releases on a 30-day cadence and patch releases on a 7-day cadence within the same minor line. +- Treat `x.9.x` as the pre-major rollover boundary: if that line is exhausted, the next planned release target should become `(x+1).0.0`. +- At cadence checkpoints, verify the active milestone due date and latest public release live, then flag owner approval when a patch or minor candidate is justified by security, regression, compatibility, packaging, or high-impact stability/performance needs. ## Non-Negotiable Compatibility Rules - Do not rename existing option/meta keys used by released versions.