diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index df3a619..7d796e7 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -24,6 +24,7 @@ For full rationale see [`AGENTS.md`](../AGENTS.md). Quick rules: - Every third-party GitHub Action is pinned to a full commit SHA with a `# vX.Y.Z` comment. Don't introduce `@v6` / `@main` / `@master` floating refs. - Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer[bot]` (shown as "Copilot" in the UI) on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. Re-request the review **programmatically** after every push via the `requestReviews` GraphQL mutation (don't wait on flaky auto-review-on-push) — see the [GitHub Copilot Review Runbook](#github-copilot-review-runbook) below and [`AGENTS.md`](../AGENTS.md#merging-a-pr). - After a develop → main merge lands and main's publish workflows complete, bump the minor in `version.json` on develop (e.g. `3.16` → `3.17`) via an isolated `bump-version-X.Y` PR. Without it, develop's next prerelease version numbers fall below main's just-shipped stable. +- A maintenance develop -> main promotion (dependency bumps, CI/doc fixes, template re-syncs - not a release) holds main's version: `git checkout main -- version.json` on the promotion branch, so main advances only a patch and develop keeps its lead. - Don't recommend `git push --force` or `--force-with-lease`; both rulesets enforce `non_fast_forward`. - `version.json`'s `publicReleaseRefSpec` is `^refs/heads/main$` — bumping the base `version` field is the only manual versioning action. diff --git a/AGENTS.md b/AGENTS.md index 42b850f..30311d6 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -43,6 +43,8 @@ Under any squash-only setup this would be a recurring pain point: each develop **Immediately after a develop → main merge lands and main's publish workflows complete, bump the minor version in [version.json](version.json) on develop.** Open a small isolated feature PR `bump-version-X.Y` (e.g. `"version": "3.16"` → `"version": "3.17"`), squash into develop, and continue feature work from there. Without this bump, develop's next NBGV-computed prerelease (`3.16.-g{sha}`) is *numerically lower* than the stable that just shipped (`3.16.`), which is visibly confusing in HISTORY.md, `--version` output, and consumer update prompts. Bumping ensures every develop prerelease is `3.17.-g{sha}` — visibly newer than main's `3.16.`. Don't bundle the bump with other work; keep the PR isolated so the version change is unambiguous in git blame. +A **maintenance** develop -> main promotion - dependency bumps, CI/doc fixes, template re-syncs, not a release - holds main's version: run `git checkout main -- version.json` on the promotion branch before opening the PR, so main advances only its git height (a patch), not its minor, and develop keeps its lead. Only a release promotion carries develop's bumped version to main. + ## Release flow PlexCleaner is a "pull" project: consumers (`docker pull ptr727/plexcleaner:latest`, `docker pull ptr727/plexcleaner:develop`, GitHub Releases) track both branches. It uses a **two-phase model** that decouples merging from publishing: