feat(release): support multiple releases per day with 4-segment CalVer

[Astro-Han]

Summary

Relax normalizeTag() regex to accept an optional 4th version segment (YYYY.M.D.N), enabling multiple releases on the same calendar day. Use dot-separated build number (e.g. 2026.5.2.2) instead of hyphen-separated (2026.5.2-2) to avoid semver pre-release sorting issues.

Why

Current YYYY.M.D CalVer format only allows one release per day — the version is tied to the calendar date with no room for a same-day second build. This blocks hotfixes and rapid iteration. OpenClaw uses a similar CalVer scheme and hit a bug with hyphen-separated build numbers (YYYY.M.D-N) because semver treats -N as a pre-release identifier, sorting it lower than the base version. Dot-separated (YYYY.M.D.N) is semver-correct and sorts properly.

Related Issue

None.

Human Review Status

Pending.

Review Focus

• normalizeTag() regex change — confirm the optional group (\.\d{1,3})? is correct
• Test coverage for new valid and invalid tag formats
• Error message wording

Risk Notes

None. The change is purely additive — existing 3-segment versions (2026.5.2) continue to work unchanged. No workflow, builder, or updater changes needed.

How To Verify

bun test scripts/verify-release.test.ts: 31 pass, 0 fail
bun test scripts/release-metadata-contract.test.ts: 9 pass, 0 fail
bun test scripts/release-workflow-contract.test.ts: 9 pass, 0 fail

Screenshots or Recordings

Not applicable — no UI changes.

Checklist

• Human review status is stated above as pending
• No related issue — standalone change
• This PR has type, scope, and priority labels, or I requested maintainer labeling
• I described the review focus and any meaningful risks
• I listed the relevant verification steps and the key result for each
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope
• Not applicable — no visible UI or copy changes
• I considered macOS and Windows impact — no platform-specific changes
• Not applicable — no docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes
• I reviewed the final diff for unrelated changes and suspicious dependency changes
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English

[coderabbitai]

📝 Walkthrough

Walkthrough

The release tag validation in the Electron desktop package is expanded to accept optional single-digit build numbers in the format vYYYY.M.D.N. The regex pattern and error messages are updated accordingly, with all related tests adjusted to validate the new behavior.

Changes

Release Tag Validation Enhancement

Layer / File(s)	Summary
Core Validation Logic packages/desktop-electron/scripts/verify-release.ts	normalizeTag regex updated to accept optional build number (.N) after date segment; error message expanded to document vYYYY.M.D.N format.
Test Coverage packages/desktop-electron/scripts/verify-release.test.ts	Tests updated to validate acceptance of single-digit build numbers (1, 2, 0) and rejection of multi-digit ones (1234); error message assertions across verifyReleasePayload and verifyStartupLog scenarios updated to reflect new format documentation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• docs: add release checklist #123: Both PRs modify the normalizeTag function in packages/desktop-electron/scripts/verify-release.ts for release tag validation.
• fix: include release version in installer artifact names #285: Both PRs modify the same release tag normalization and verification code and tests in packages/desktop-electron/scripts/verify-release(.ts/.test.ts).

Suggested labels

enhancement, P3, desktop

Poem

🐰 A build number hops in today,
vYYYY.M.D.N leads the way,
Tests leap and bound with delight,
Validation shines ever more bright!
One digit, two, three—all just right! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes the main change: supporting multiple releases per day through a 4-segment CalVer format.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description is comprehensive and well-structured, covering all required sections including summary, rationale, review focus, risk assessment, and verification steps.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch pawwork/multi-release-per-day

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request updates the release tag validation and normalization logic to support an optional fourth segment (build number) of up to three digits. The regex in normalizeTag and the associated error messages were updated, along with corresponding test cases in verify-release.test.ts. A suggestion was made to refine the regex to prevent leading zeros in the build number segment to ensure more consistent tag naming.