Commits on Apr 23, 2026

1. ci: adjust 3.x branch references (#16358) …

   # Overview
   
   Adapt the 3.x branch for its new role as the v3 maintenance line now
   that v4 development has begun on `main`. Retargets release tooling, CI,
   templates, and documentation links from `main` to `3.x`, and removes
   workflows and GitHub surfaces that only fire from the default branch.
   
   ## Key Changes
   
   - **Release tooling retargeted to 3.x**
   
     - `tools/releaser` creates GitHub draft releases against `3.x`.
   - `create-payload-app` defaults its template, example, and
   skill-download branch refs to `3.x`.
   - `.github/workflows/main.yml` triggers on pushes to `3.x`; the no-op
   `publish-canary` job was dropped.
   - `.github/workflows/publish-prerelease.yml` drops the nightly cron and
   the `canary` release type; on-demand `internal` / `internal-debug`
   builds remain.
   
   - **Default-branch-only workflows and surfaces removed**
   
   - Deleted workflows driven by `schedule:`, `release:`, `issues:`, and
   `pull_request_target:` events (activity-notifications,
   audit-dependencies, dispatch-event, label-on-change, lock-issues,
   post-release, post-release-templates, pr-title, stale, triage), along
   with their exclusively-consumed custom actions (`activity`,
   `release-commenter`, `triage`) and the orphaned `.github` pnpm
   workspace.
   - Deleted `.github/ISSUE_TEMPLATE/`, `PULL_REQUEST_TEMPLATE.md`,
   `comments/invalid-reproduction.md`, and `dependabot.yml` — GitHub serves
   all of these only from the default branch.
   
   - **Docs, templates, and source links retargeted**
   - Sweep of `github.com/payloadcms/payload/(tree|blob)/main/…` and
   `raw.githubusercontent.com/payloadcms/payload/(refs/heads/)?main/…`
   references across docs, READMEs, templates, examples, and test source,
   rewritten to `3.x`.
   - Also handles URL-encoded `%2Fpayload%2Ftree%2Fmain%2F…` forms (e.g.
   Vercel deploy-button links) and the one-click-deploy link added
   post-rebase in 5a39afc.
   - Left untouched: `shields.io` workflow-filename badges (reference
   `main.yml`, not a branch), cross-repo
   `payloadcms/website/refs/heads/main/…` links, and all `main` workflow
   files on `main` itself (this PR is scoped to 3.x).
   
   - **Template variations regenerated**
   - `pnpm script:gen-templates` output against workspace 3.84.0: bumps
   `payload`, `@payloadcms/*` deps in template `package.json` files,
   refreshes `importMap.js` for admin-rendered templates, and re-timestamps
   the initial migrations for `with-postgres`, `with-vercel-postgres`, and
   `with-vercel-website`.
   
   ## Design Decisions
   
   - **Per-branch hardcoding over runtime branch detection.** Each branch
   hardcodes its own ref (`3.x` here, `main` on v4). Simpler than
   branch-aware logic, trivially reviewable, and the Phase 2 swap (v4 →
   `latest`) stays a small diff.
   - **Delete dormant workflows rather than trim triggers.** Workflows
   whose only triggers are default-branch-only were removed entirely along
   with their private actions. Leaving hollowed-out files on 3.x would
   imply functionality that never fires. Removing them also shrinks
   `dist`-bundle noise (~88k of the line-deletion count is pre-built action
   bundles).
   - **Discord release notifications stay on `main`.** Release events
   always run from the default branch regardless of where the release was
   cut, so `main`'s `post-release.yml` continues announcing both v3 patches
   (from 3.x) and v4 betas. No 3.x-side copy is needed.
   - **No npm dist-tag collision in Phase 1.** 3.x stays on `latest`;
   `main` will publish v4 betas to `beta`. Phase 2 renames the 3.x package
   to `payload-3`, freeing `latest` for v4 — so no per-major dist-tag
   scheme is needed.
   
   ## Overall Flow
   
   npm channels during Phase 1:
   
   | Branch | Stable dist-tag | Scheduled | On-demand |
   | --- | --- | --- | --- |
   | `3.x` | `latest` | — | `internal`, `internal-debug` |
   | `main` | `beta` | nightly `canary` | `internal`, `internal-debug` |
   
   Release events (draft-release publish) always dispatch from the default
   branch — which is `main` — regardless of where the release was cut. A v3
   patch published from `3.x` therefore flows through `main`'s post-release
   workflows:
   
   ```mermaid
   sequenceDiagram
       actor Dev as Maintainer
       participant ThreeX as 3.x branch tooling
       participant NPM as npm
       participant GH as GitHub
       participant MainWF as main's post-release.yml
       participant Discord
   
       Dev->>ThreeX: pnpm release (v3.x.y)
       ThreeX->>NPM: publish at latest
       ThreeX->>GH: create draft release (target 3.x)
       Dev->>GH: publish release
       GH->>MainWF: release:published (fires from default branch)
       MainWF->>MainWF: release-commenter filters tag major (v3)
       MainWF->>GH: comment on v3 PRs/issues
       MainWF->>Discord: announce release
   ```
   
   The same workflow path handles v4 releases from `main`, with the
   release-commenter filtering to `v4` tags.

   

   denolfe authored Apr 23, 2026
   Configuration menu

   • View commit details
   • Copy full SHA for b6131f7
   • Browse repository at this point

   Copy the full SHA

   b6131f7 View commit details

   Browse the repository at this point in the history

2. chore(release): v3.84.1 [skip ci]

   

   denolfe committed Apr 23, 2026
   Configuration menu

   • View commit details
   • Copy full SHA for ea39d8a
   • Browse repository at this point

   Copy the full SHA

   ea39d8a View commit details

   Browse the repository at this point in the history