Evaluate skipping RCs for non-network-upgrade releases

[rjan90]

Context

Follow-up from BigLep's review on #13666:

I wonder if this process could simplify further if we didn't do an RC and directly cut a new release from master. (I'm wondering if we only do RC mode when we're around network upgrades, otherwise cut release from master.)

The current release issue template assumes an RC track for every release. For releases that are not associated with a Filecoin network upgrade, the RC step may add process overhead without a clear release-quality benefit.

Question to resolve

Should Lotus skip RCs for releases that are not associated with a Filecoin network upgrade and cut the stable release directly from master or the release branch?

Things to evaluate

• Which release types could skip RCs: patch only, non-network-upgrade minor releases, Miner releases, or all non-network-upgrade releases?
• Which cases should still require RC mode: network upgrades, large/risky changes, dependency or actor-bundle changes, security releases, or maintainer discretion?
• Whether a no-RC release still creates release/vX.Y.Z and/or release/miner/vX.Y.Z branches before publishing.
• How CI, draft GitHub release creation, changelog prep, release announcement timing, homebrew/docs automation, and security-advisory staging would change.
• How the release issue template should name and structure steps currently grouped under Before RC1 if there may be no RC.
• Whether LOTUS_RELEASE_FLOW.md should define a default policy such as "RCs required for network upgrades; direct stable releases allowed for routine non-network-upgrade releases."

Done criteria

• Decide whether no-RC releases are allowed and under what conditions.
• Document the policy in LOTUS_RELEASE_FLOW.md if accepted, or record why the current always-RC process remains preferred.
• Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md and any release CLI behavior needed to support the chosen flow.
• Make sure the generated release issue remains agent-executable for both RC and no-RC tracks.

Links

• Source review: docs(release): v1.36.1 release template improvements #13666 (review)
• Current release template PR: docs(release): v1.36.1 release template improvements #13666
• Release issue that prompted the template work: Lotus Node and Miner v1.36.1 Release #13660

[rvagg]

I think network upgrade releases could still do an RC, so we don't have to rewrite that whole flow (for now), and if we have more regular releases with only in the order of ~10-20 commits, then RC not really a big deal. We could decide to do an RC depending on that changes included, if there's some big feature addition we're a little worried about then an RC might be appropriate. Default to no-RC, put out an RC if we have something that we think deserves some more humility in our ability to get it right. That'd be larger refactors or feature additions, we haven't had many of them recently.

[rjan90]

Perfect timing on your comment Rod, was just about to post the plan that I had written up/chatted with Codex about for trying a no-RC flow:

1. Update LOTUS_RELEASE_FLOW.md to make weekly Lotus Node releases the stated goal, and document the new default policy:
   • network-upgrade releases require RC mode;
   • routine non-network-upgrade releases use a direct stable/no-RC flow by default;
   • maintainers can require RC mode for large/risky changes, actor-bundle or consensus-sensitive changes, major dependency changes, migrations, API breaks, security handling, or release-owner discretion.
2. Update the generated release issue shape to Release Setup -> RCs -> Stable Release -> Post-Release.
   • For no-RC releases, keep the RCs section present but explicitly mark it skipped/not applicable so the issue remains agent-executable and consistent.
3. Add --release-flow to cmd/release create-issue with values auto, rc, and no-rc.
   • auto + network upgrade => rc.
   • auto + no network upgrade => no-rc.
   • Explicit rc always generates the RC + stable path.
   • Explicit no-rc generates the stable-only path, with RCs marked skipped.
   • Reject no-rc with --network-upgrade for now.
4. Update .github/workflows/create-release-issue.yml to pass the new flow option, ignore rc1-date for no-RC releases, and remove the stale major level option.
5. Keep creating release/vX.Y.Z and/or release/miner/vX.Y.Z branches from origin/master before publishing stable, so the existing release workflow, asset generation, tags, changelog process, docs automation, and Homebrew automation continue to work.
6. Add no-RC guardrails to the stable release checklist: green CI, resolved dependencies, no unresolved release/backport blockers unless intentionally deferred, changelog review, draft GitHub release body review, release-owner approval, and security-advisory staging check.
7. Pilot this on the next two routine non-network-upgrade Lotus Node releases, then keep it as the standard weekly path if the pilot does not reveal release-quality issues.

I am going to put this behind a draft PR so we can review the generated issue output and try the no-RC flow before relying on it.

[rjan90]

Draft PR implementing the plan is open here: #13697

It includes the documented weekly/no-RC policy, --release-flow support, the Release Setup -> RCs -> Stable Release -> Post-Release generated issue structure, workflow input cleanup, and validation of generated no-RC/RC issue output.