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

.github/workflows/release.yml

@@ -124,7 +124,13 @@ jobs:
   # Windows Build - x64
   # =============================================================================
   build-windows-x64:
-    runs-on: windows-latest
+    # Pinned alongside build-windows-arm64 (see the comment block on
+    # that job for the full story).  The Win-x64 build succeeded on
+    # `windows-latest = windows-2025-vs2026` for v4.2.2, but the
+    # underlying VS 2026 maxBuffer issue could trip x64 too on a
+    # future runner rotation.  Pinning both today is cheaper than
+    # debugging the same class of failure again in a few months.
+    runs-on: windows-2022
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4
@@ -186,7 +192,27 @@ jobs:
   # Windows Build - ARM64
   # =============================================================================
   build-windows-arm64:
-    runs-on: windows-latest
+    # Pin to windows-2022 (the only label that still gets VS 2022):
+    # `windows-latest` rotated to the VS 2026 variant on Jun 8 and
+    # broke this job. v4.2.1 (Jun 7) ran on `Image: windows-2025`
+    # which AT THE TIME used the `win25` runner-images branch with
+    # VS 2022.  GitHub has since re-bound the `windows-2025` label
+    # to the `win25-vs2026` branch (VS 2026) — verified by an
+    # explicit `runs-on: windows-2025` resolving to `Image:
+    # windows-2025-vs2026` and failing identically.  So `windows-
+    # 2025` is no longer a working label for our purposes;
+    # `windows-2022` (Windows Server 2022 + VS 2022) is the only
+    # remaining GitHub-hosted image that ships VS 2022.
+    #
+    # The failure mode: VS 2026's `vswhere`/PowerShell enumeration
+    # emits enough metadata that node-gyp's child_process stdout
+    # read overflows with `RangeError
+    # [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]` — node-gyp then reports
+    # "Could not find any Visual Studio installation to use" and
+    # the ARM64 cross-compile of `@serialport/bindings-cpp` fails.
+    # When node-gyp / electron-builder ship a fix we can revert to
+    # `windows-latest`.
+    runs-on: windows-2022
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4

package.json

@@ -1,7 +1,7 @@
 {
   "name": "open-plc-editor",
   "description": "OpenPLC Editor - IDE capable of creating programs for the OpenPLC Runtime",
-  "version": "4.2.10",
+  "version": "4.2.11",
   "license": "GPL-3.0",
   "author": {
     "name": "Autonomy Logic"

src/frontend/data/constants/app-version.ts

@@ -1,3 +1,3 @@
 /**
  * Single source of truth for the OpenPLC application version, SHARED
  * byte-for-byte between openplc-web and openplc-editor.
@@ -18,4 +18,4 @@
  * compares a per-deploy `BUILD_ID` (git commit SHA), not this version, so a
  * stale tab is detected on every deploy even without a version bump.
  */
-export const APP_VERSION = '4.2.10'
+export const APP_VERSION = '4.2.11'