ci: change release wf from daily to weekly freq

[nk1408]

Pull Request

Description

1. Change release workflow frequency to weekly

Changes Made

1. release.yml - Change to cron scheduling (weekly 9am)

Checklist

• I have read the Contributor Guidelines.
• I have performed a self-review of my own code and ensured it follows the project's coding standards.
• I have tested the changes locally following ManualTestingProcess.md, and all tests related to this pull request pass.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation, if applicable.
• I have added appropriate unit tests, if applicable.

[claude]

Code Review

Overview

This PR changes the release workflow trigger from push-to-main (continuous delivery) to a weekly cron schedule (every Monday at 15:00 UTC). The workflow_dispatch manual trigger is preserved. The change is minimal, focused, and the comment explaining the UTC/CST/CDT offset is a nice touch.

---

What's Good

• Small, focused diff — only 4 lines changed, exactly what's needed.
• Clear comment explaining the UTC offset and DST caveat. This is genuinely useful for future maintainers.
• workflow_dispatch preserved — allows emergency manual releases when the weekly cadence is too slow.
• Cron expression is correct: 0 15 * * 1 means every Monday at 15:00 UTC ✓

---

Concerns and Discussion Points

1. Hotfix gap — critical fixes won't auto-release until Monday

By removing the push: trigger, any security patch or critical bugfix merged to main mid-week won't be published to npm until the next Monday. The only escape valve is a manual workflow_dispatch run. Consider whether this tradeoff is acceptable, or whether both triggers can coexist to reduce noisy releases while still allowing immediate delivery for urgent fixes.

2. semantic-release will batch all week's commits into one release

This is likely intentional, but worth confirming. Commits from Monday through Sunday will all be grouped into a single Monday release. If a breaking change lands Tuesday and a feature lands Thursday, users see one large release note rather than two discrete ones.

3. GitHub Actions scheduled workflow reliability

GitHub does not guarantee on-time execution of scheduled workflows — they can be delayed during high platform load, and workflows in repos with no activity for 60 days are automatically disabled. Neither is likely a blocker here, but worth being aware of.

4. No-op runs on Mondays with no new commits

If nothing has been merged since the last release, semantic-release will run the full build pipeline (install, build, audit, signatures) and exit without publishing. This is harmless but wastes CI minutes. A guard step using git log to check for unreleased commits could short-circuit early.

---

Nits

• The offset comment is accurate: CST = UTC-6 so 15:00 UTC = 9 AM ✓, CDT = UTC-5 so 15:00 UTC = 10 AM ✓. Well done.

---

Summary

The change is clean and correct. The main decision for the team is concern 1 — whether losing automatic push-triggered releases for hotfixes is an acceptable tradeoff. If weekly batching is the deliberate strategy and the team is comfortable using workflow_dispatch for urgent releases, this PR is ready to merge as-is.