From 346fd6d74d734cee643d81a7d4ec35f611cbd6c9 Mon Sep 17 00:00:00 2001 From: InstaZDLL Date: Tue, 15 Sep 2026 19:35:09 +0200 Subject: [PATCH] fix(deps): hold both windows names, not just windows-core majors MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I claimed the rule already reached a lone 0.63 because Dependabot classifies a 0.x minor-position bump as semver-major, and cited this repository's history as proof. That inference was too strong. What the history shows is how `groups` behaves — no 0.x bump of that shape has ever landed inside cargo-patch-and-minor — and `groups` and `ignore` are not obliged to classify alike. GitHub documents SemVer as plain major.minor.patch, which makes 0.62 -> 0.63 a minor, and nothing authoritative settles the 0.x case either way. So stop betting on the classification. Both names are now held back from major and minor alike, which is correct under either reading, and the mirrored failure the previous rule risked is gone with it: `windows` was left free, so a paired 0.63 would have bumped `windows` alone and desynchronised in the other direction — the same defect as #642 with the two crates swapped. Patches stay automatic and are safe by construction: both names remain inside 0.62.x, where Cargo unifies them onto one version regardless. Accepted cost, written at the rule: an ignore can also hold back a security update needing a minor bump. --- .github/dependabot.yml | 37 +++++++++++++++++++++------------ src-tauri/crates/app/Cargo.toml | 7 ++++--- 2 files changed, 28 insertions(+), 16 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index b5c3b0aa..7fb3727b 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -50,27 +50,38 @@ updates: # windows-rs versions its support crates on their own lines, and 0.100.0 # renumbered that entire layer (windows-core, -implement, -interface, # -result, -link) while the generated-bindings crates above it stayed - # put -- `windows` is still 0.62.2. So a major for `windows-core` alone - # is never mergeable. Grouping does not help: a group still opens a PR - # when only one of its members has a release. + # put -- `windows` is still 0.62.2. So neither name can move on its own, + # in either direction, and a group does not express that: a group still + # opens a PR when only one of its members has a release. # - # "Major" covers more than it looks. For a 0.x crate Dependabot treats - # the minor position as the breaking one, so 0.62 -> 0.63 is a - # semver-major update here just as 0.62 -> 0.100 is. Every 0.x bump of + # Hence BOTH are held back from everything but patches, and the pair is + # bumped by hand, in one commit, when upstream realigns. Patches stay + # automatic and are safe by construction: both names remain inside + # 0.62.x, which Cargo unifies onto a single version anyway. + # + # Major *and* minor, because which of the two a 0.x bump like + # 0.62 -> 0.63 counts as is NOT settled. GitHub documents SemVer as + # plain major.minor.patch, which makes it minor; yet every 0.x bump of # that shape in this repository has arrived as its own PR instead of # inside cargo-patch-and-minor (quick-xml 0.41 -> 0.42, lofty 0.24 -> - # 0.25, wasapi 0.23 -> 0.24), which is what that classification looks - # like from the outside. Adding semver-minor to the rule would suppress - # nothing extra, and would risk holding this name back while `windows` - # moved -- the same desync, mirrored. + # 0.25, wasapi 0.23 -> 0.24), which is what "major" looks like from the + # outside -- and `groups` and `ignore` are not obliged to classify + # alike. Naming both costs nothing and is correct under either reading. + # Do not "simplify" this back to majors only without settling that. # - # `windows` itself is deliberately NOT ignored. The day it offers a major - # is the day the pair can move, and that PR is the signal to bump both by - # hand, in one commit. + # Known cost, accepted: an ignore rule can also hold back a security + # update that needs a minor bump. Patch-level advisories still flow, and + # a desync is a build failure on every Windows job, which a stale + # binding is not. ignore: + - dependency-name: "windows" + update-types: + - "version-update:semver-major" + - "version-update:semver-minor" - dependency-name: "windows-core" update-types: - "version-update:semver-major" + - "version-update:semver-minor" - package-ecosystem: github-actions directory: "/" diff --git a/src-tauri/crates/app/Cargo.toml b/src-tauri/crates/app/Cargo.toml index b425a4c3..1fa323e0 100644 --- a/src-tauri/crates/app/Cargo.toml +++ b/src-tauri/crates/app/Cargo.toml @@ -331,9 +331,10 @@ windows = { version = "0.62", features = [ # Pinning the same 0.62 keeps one copy in the graph; a mismatched one # would compile into a *different* `IUnknownImpl` and the sink would no # longer satisfy the interface. Already in the lockfile as a dependency -# of `windows` itself, so this adds a name, not a crate. Dependabot is told -# to skip majors here for the same reason (`.github/dependabot.yml`): moving -# this line alone is never valid, whichever of the two upstream releases first. +# of `windows` itself, so this adds a name, not a crate. Dependabot is held +# back from both names above patch level for the same reason +# (`.github/dependabot.yml`): moving either line on its own is never valid, +# so the pair is bumped by hand when windows-rs realigns them. windows-core = "0.62" # macOS-only: opt-in bit-perfect native DSD via DoP (#495 / #497).