chore: back-merge main + bump version to 4.2.11 (unblocks release PR #1006)

[thiagoralves]

Two changes that both need to land on development before release PR #1006 can merge correctly.

---

1. Back-merge main — unblocks #1006

#1006 (development → main, 4.2.11) is approved with all checks green but cannot merge: GitHub reports mergeStateStatus: BEHIND. main's protection sets required_status_checks.strict: true ("require branches to be up to date") with enforce_admins: true, so it cannot be clicked through.

development was 124 commits ahead of main but also 27 commits behind it — the merge commits GitHub created on main for every past release PR (#459 … #964, plus the v4.2.10 merge), plus two CI hotfixes committed directly on main.

A PR with head: main would not work: development's protection is also strict, so such a PR would itself be BEHIND. Hence this branch, which contains development's tip and merges main into it.

The one real content change is .github/workflows/release.yml (+28/-2): the windows-2022 pin for both Windows release jobs (35d8b90, 6c86e0b). That pin was a direct hotfix on main and never reached development, which still had both jobs on runs-on: windows-latest. It works around VS 2026's vswhere output overflowing node-gyp's stdout buffer (ERR_CHILD_PROCESS_STDIO_MAXBUFFER), which breaks the ARM64 cross-compile of @serialport/bindings-cpp.

Merging #1006 without this back-merge would have reverted the pin on main and broken the v4.2.11 Windows ARM64 release build. No conflicts — verified with git merge-tree --write-tree beforehand, and the real merge touched only that file.

2. Version bump to 4.2.11

Carried here so #1006 promotes the correct version to main rather than needing a second PR after the tag.

File	4.2.10 → 4.2.11
src/frontend/data/constants/app-version.ts	APP_VERSION — what the About modal renders
package.json	what electron-builder stamps, and what the v4.2.11 tag must match

Shipping only the package.json half is what left About showing 4.2.6 on the 4.2.7 and 4.2.8 releases, so both move together.

Other 4.2.10 occurrences in the tree are deliberately untouched — they are semver-comparison fixtures in semver.test.ts / runtime-version-gate.test.ts using it as an arbitrary version, not the app version.

Mirror gate

APP_VERSION lives under src/frontend/, so sync / Shared Surface Sync byte-compares it against openplc-web. The identical edit is in Autonomy-Logic/openplc-web#667 (base development).

Verified locally: app-version.ts is byte-identical across both branches (matching md5) and compare-surfaces.py reports match: True, total_diffs: 0.

The sync gate compares against web at pull_request.base.ref, then — on mismatch — passes if an open web PR targeting that same base makes the surfaces match. So this PR's sync check is satisfied by web#667 while it is still open, and fully satisfied once it merges.

Merge order

1. web#667 → web development
2. this PR → editor development
3. Release 4.2.11 #1006 leaves BEHIND, checks re-run, merge it
4. tag v4.2.11 on editor main

⚠️ Before step 3, a web development → main PR must be open (or merged), otherwise #1006's own sync check compares editor development at 4.2.11 against web main at 4.2.10 and fails. See the note on #1006.

Follow-up

This BEHIND gap is structural: nothing in the release ritual merges main back down, so it recurs every release. Either add a back-merge step after each promotion or automate it.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved Windows release build reliability by pinning build jobs to a stable runner version.
  • Prevented build failures associated with newer Windows runner environments.

• Release

  • Updated the application and package version to 4.2.11.

[coderabbitai]

Walkthrough

The release workflow pins Windows x64 and ARM64 build jobs to windows-2022. The package version and frontend APP_VERSION constant change from 4.2.10 to 4.2.11.

Changes

Release updates

Layer / File(s)	Summary
Pin Windows build jobs .github/workflows/release.yml	The Windows x64 and ARM64 jobs now use windows-2022. Comments document Visual Studio and node-gyp failure conditions.
Update release version package.json, src/frontend/data/constants/app-version.ts	The package version and exported APP_VERSION constant change to 4.2.11.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• Autonomy-Logic/openplc-editor#564: Updates the same release workflow and Windows runner configuration.
• Autonomy-Logic/openplc-editor#855: Updates the package and frontend application versions.
• Autonomy-Logic/openplc-editor#967: Updates the same package and frontend version fields for a release.

Suggested reviewers: joaogsp

Poem

A rabbit checks the release track,
Windows runners stay safely back.
The version hops to 4.2.11,
Builds follow a stable path to heaven.
Hop, hop, the release is set!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.
Title check	✅ Passed	The title clearly identifies the back-merge, version bump, and release PR it unblocks.
Description check	✅ Passed	The description clearly explains the back-merge, workflow pin, version bump, validation, merge order, and follow-up, but omits the template checklist.

✨ 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 chore/back-merge-main-into-development

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[Gustavohsdp]

Approved — release plumbing, CI green.

Checked the one thing that matters here per CLAUDE.md: APP_VERSION and package.json.version are both 4.2.11, so the About dialog won't lag the binary the way 4.2.7/4.2.8 did.

Reminder for the release: package.json.version needs the same value in openplc-web, and the tag v4.2.11 goes on the editor's main to trigger the build.