From a666aaa3b64a5b266e317759aaac2ba82d9982a9 Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Fri, 14 Aug 2026 20:37:28 +0200 Subject: [PATCH 1/2] chore(release): set main to 1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The stable tag is published and every byte of it is already on main — the release branch was built entirely from cherry-picks, so the only thing main still lacks is the version number itself. Doing this instead of merging the sync PR the promote workflow opened. That PR replays 26 commits, 23 of which are the cherry-picks main already has under different SHAs, and one of those (db101b91) touches NewEditorShell.tsx — the same file 210e5da2 changed after the release branch forked. Rebasing a stale version of that file over a newer one is how a merge silently drops the newer change, and the workflow's own rebase already failed five times against it. `feat(editor): delete a project from the Open project dialog` is deliberately held for 1.10 and must survive this sync. Verified before writing: `git diff main v1.9.5` is empty across every path except package.json, package-lock.json, and the files that feature adds. --- package-lock.json | 4 ++-- package.json | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/package-lock.json b/package-lock.json index 59efaa90..03324d6b 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "openscreen", - "version": "1.9.2", + "version": "1.9.5", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "openscreen", - "version": "1.9.2", + "version": "1.9.5", "dependencies": { "@fix-webm-duration/fix": "^1.0.1", "@langchain/anthropic": "^1.3.26", diff --git a/package.json b/package.json index 47a386c2..76f8c962 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "openscreen", "private": true, - "version": "1.9.2", + "version": "1.9.5", "type": "module", "packageManager": "npm@10.9.4", "engines": { From 4835ebb3757df6f86133661edc286d33e91580e2 Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Fri, 14 Aug 2026 20:45:11 +0200 Subject: [PATCH 2/2] fix(nix): refresh npmDepsHash for the 1.9.5 lockfile MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bumping the version rewrites package-lock.json, which changes the hash Nix records for the npm dependency set — so nix-check failed on the previous commit here. The value is the one CI computed. This is the same edit `bump-nix-package.yml` makes after a stable release; it derives the hash from the lockfile at the tag, and that lockfile is now byte-identical to this branch's, so both compute sha256-fBNFOicysW5FAbPERqzXUzIcQ0C+ICsQFtGt1agF1VI=. Doing it here keeps main coherent in one commit instead of leaving it briefly stale. Worth noting the tag itself ships the old hash: the release-branch bumps are [skip ci], so nothing checks it there, and the post-release workflow is what fixes it. That is the designed flow, not a defect — but it does mean `nix build` at a stable tag fails until that PR lands. --- nix/package.nix | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nix/package.nix b/nix/package.nix index 111787a1..4da63450 100644 --- a/nix/package.nix +++ b/nix/package.nix @@ -37,7 +37,7 @@ buildNpmPackage { ); }; - npmDepsHash = "sha256-I0UeoZ8kWHwg2dZDHhCjBIo5BkPWi5c0DwrMywiphIo="; + npmDepsHash = "sha256-fBNFOicysW5FAbPERqzXUzIcQ0C+ICsQFtGt1agF1VI="; env.ELECTRON_SKIP_BINARY_DOWNLOAD = "1";