Put the RELEASE_CHECKLIST.md back to using `main` branch

[abernix]

TL;DR: Bringing main back as the "stable" release branch after 7+ months of using only dev. This is stage 1 of a 3-stage plan to automate our release process.

Why i'm doing this

Back in early 2024 (around v1.41.0, just before we started supporting multiple release lines for 2.x), we stopped using "main" as our stable release branch — the idea being that it would simplify our workflows.

In retrospect, it made things more difficult — and that's spoke as the person who has largely been doing the releases, so it hasn't unblocked other people doing the releases either! I have to fix that.

The intention was right, but it actually has made it more difficult to automate toward a solution and it worked against GitHub workflows which, while sometimes annoying — like conflicts — were a reality of managing multiple active release lines, where git conflicts are just a reality we need to grapple with to some extent.

What's actually happened is that our release PRs are no longer natural: They're bound to end up in unreconcilable merge conflicts. I'm not talking about normal conflicts you can resolve in the GitHub UI, or with another PR. I'm talking about conflicts that emerge after a PR is approved but before it can actually merge — conflicts that require re-running CI, re-approving, going into the CLI to manually merge it, disabling branch protection rules in order to actually merge it, etc. When that happens during a release window or on a time-sensitive fix, it genuinely renders the PR as a concrete obstacle.

And in addition to preventing automation, it also rendered the approval workflow a bit hand-wavy where it was no longer tightly controlled by policy.

One of the big arguments previously was conflicts which existed in a different place: on docs PRs, which classically targeted main in order to go live right away. While that was true, those conflicts were reconcileable, though annoying. But, i'm somewhat confident we can fix that with Mergify rules and automation — that's a tooling problem, not a branching strategy problem.

What this PR does

This PR re-introduces main as the stable release branch, but preserves all the improvements we've made to RELEASE_CHECKLIST.md over the last 7 months.

Specifically:

• main becomes the "stable" ("released") branch again
• dev remains the active development trunk
• Release PRs will merge into main after approval (which makes them WAY more clear WHAT you're releasing!)

• We'll reconcile main back to dev after each release (just like we used to), but with automation to help

The larger 3-stage plan

• Stage 1 (this PR): Re-introduce main as the stable branch. Get us back to a known-good state.
• Stage 2 (next PR): Add GitHub Actions automation to trigger release workflows without requiring manual CLI commands. This removes human error and makes the process repeatable.
• Stage 3 (final PR): Add CLI automation that utilizes the GitHub Actions from stage 2. This gives us the best of both worlds — automated workflows with CLI convenience.

This will be a bit trial and error as tends to be the case with CI tweaks, but ultimately the goal is that releases become almost entirely automated.

I'll be careful with how I reintroduce this and test it, but I've lived through all the edge cases at this point, so I feel pretty good nurturing it back to a better place. Overall, this isn't about going back to the old way — it's about fixing something that demonstrably doesn't work in practice, even if it looked good on paper.

[apollo-librarian[bot]]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: c041e83c623abcef96e28521 Build Logs: View logs

[github-actions[bot]]

@abernix, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.