chore(beta): merge master into releases/v3-beta (second sync) - #5821
Merged
Conversation
…build (#5805) Fix 32-bit build: type maxArchiveTotalSize as int64 The updater's maxArchiveTotalSize constant is 2 GiB (2147483648). As an untyped constant it defaults to int when passed to fmt.Errorf, and on 32-bit targets (e.g. GOARCH=386) int is 32 bits, so the value overflows and the build fails: cannot use maxArchiveTotalSize (untyped int constant 2147483648) as int value in argument to fmt.Errorf (overflows) Type the constant int64 so it stays int64 at the format calls. Every other use is already int64 arithmetic, so behaviour is unchanged. Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
CONTRIBUTING.md never said what licence contributions come in under, whether a CLA applies, or whether sign-off is required. That is a routine question for anyone contributing from inside a company, and the answer being implicit means each person has to ask or guess. States the existing position rather than introducing a new one: MIT in, MIT out, no CLA, no DCO trailer, and third-party code disclosed in the PR. Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8 Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
… contributions are accepted under
…nic (#5793) fix(v3): guard nil AllowDarkModeForWindow to avoid startup panic on Windows 1809 pkg/w32/theme.go loads the undocumented dark-mode uxtheme exports (including AllowDarkModeForWindow) only on Windows build >= 18334, so on older builds such as Windows 10 1809 / Windows Server 2019 (build 17763) the package-level AllowDarkModeForWindow is nil. The Dark and system-dark branches of (*windowsWebviewWindow).run called it unguarded, so a window with Windows.Theme == Dark (or SystemDefault while the OS is in dark mode) panicked on startup with a nil pointer dereference before the window was shown. w32.SetMenuTheme already guards the identical call. Extract the call into an applyDarkMode method, which nil-guards it, and use it from both branches so the window degrades gracefully instead of crashing. Fixes #5792 Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
…lowDarkModeForWindow to avoid startup panic
The npm package version was produced by `npm version prerelease`, which increments the trailing numeric identifier and knows nothing about the release channel. That is how the two series drifted: the CLI went alpha -> alpha2 -> beta while npm kept counting alpha.N. Today the CLI is v3.0.0-alpha2.117 and npm is 3.0.0-alpha.97, and at beta a v3.0.0-beta.0 CLI would have shipped alongside an "alpha" runtime, with every upgrading user needing to be told the mismatch was expected. The runtime version now comes from v3/internal/version/version.txt, the same file go:embed puts into the CLI, so the two always agree. Because the version now only moves when version.txt moves, a run triggered by a runtime source change between releases would try to republish an existing version. Such runs now skip the publish step while still committing regenerated assets, and version.txt is added to the trigger and detection paths so a release that moves it does publish. Merging this publishes nothing: a workflow-file-only change does not match the detect job's file lists, so the publish job does not run. The next publish happens when version.txt next moves, and it will be 3.0.0-alpha2.117 rather than 3.0.0-alpha.98. That sorts higher, so nothing downstream breaks. Verified: actionlint clean; version derivation exercised for both the current master value and the beta value; the already-published guard correctly detects 3.0.0-alpha.97 as present and 3.0.0-beta.0 as absent. Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8 Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
Picks up the contribution terms (#5816), the release workflow hardening (#5815), the runtime/CLI version lockstep (#5820) and the crash fixes merged since the first sync. Clean merge, no conflicts. The branch was six commits behind again within hours of the first sync, which is why this is now an audit blocker rather than something to remember: a release branch that quietly ages is how a release ships without fixes everyone believes are in it. Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
Documentation
leaanthony
approved these changes
Jul 26, 2026
leaanthony
left a comment
leaanthony
left a comment
Member
There was a problem hiding this comment.
Six commits of drift in a few hours makes the point better than the first sync did. Clean merge, invariants checked, and the new audit blocker means the next one gets caught rather than noticed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second sync. The branch was six commits behind master again within hours of the first one (#5818), which is the whole point: a release branch does not announce that it is aging, it just quietly stops containing things.
Clean merge, no conflicts. Picks up:
legal-provenanceaudit warning on this branchInvariants checked after merging
version.txtstillv3.0.0-beta.0faq.mdxandstatus.mdxpublish-npm.ymlrelease-v3.ymlThis is now enforced
relmangained arelease-branch-currentblocker that compares the release branch against its base and fails the audit when it falls behind, with the fix in the message. It caught this drift:Re-syncing immediately before the tag should be a step in the release runbook, not something anyone has to remember.