chore(deps): Bump the minor-and-patch group with 3 updates - #93
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps Avalonia.Controls.DataGrid from 12.1.0 to 12.1.2 Bumps Daqifi.Core from 1.3.0 to 1.4.0 Bumps SQLitePCLRaw.bundle_e_sqlite3 from 3.0.4 to 3.0.5 --- updated-dependencies: - dependency-name: Avalonia.Controls.DataGrid dependency-version: 12.1.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Daqifi.Core dependency-version: 1.4.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: SQLitePCLRaw.bundle_e_sqlite3 dependency-version: 3.0.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Avalonia.Controls.DataGrid dependency-version: 12.1.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Daqifi.Core dependency-version: 1.4.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: SQLitePCLRaw.bundle_e_sqlite3 dependency-version: 3.0.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Avalonia.Controls.DataGrid dependency-version: 12.1.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Daqifi.Core dependency-version: 1.4.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: SQLitePCLRaw.bundle_e_sqlite3 dependency-version: 3.0.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
.NET
Contributor
Author
|
Looks like these dependencies are updatable in another way, so this is no longer needed. |
Contributor
Author
|
Superseded by #95. |
dependabot
Bot
deleted the
dependabot/nuget/Daqifi.Avalonia/minor-and-patch-9ddc769788
branch
August 10, 2026 13:18
tylerkron
added a commit
that referenced
this pull request
Aug 31, 2026
check_dependabot_claims.py only looked at .csproj PackageReference pins, so a transitive-only update — a security bump to something no csproj names — would have failed the check. That is the most costly PR to block on a false positive. Lock files are safe to trust here: in #130 the lock file recorded Daqifi.Core at 1.3.0 right alongside the csproj, because the bump landed nowhere. Re-verified against the repo's real Dependabot PRs — still passes #93/#95/#96, still fails #130 on all ten unapplied claims. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tylerkron
added a commit
that referenced
this pull request
Aug 31, 2026
… one Qodo, correctly: accepting a claim because SOME manifest reached the new version lets a grouped multi-directory PR move one head and leave another stale. Avalonia.Fonts.Inter is pinned by three projects here, so that is a real input shape, not a hypothetical. Now every project pinning the package must be at the claimed version — scoped to the `directories` Dependabot actually manages, read from dependabot.yml at check time. The scope matters in both directions: the iOS head is not managed, so its pins drift on purpose and must not fail a PR that could never have touched them; and if the list grows later, the check grows with it. An unreadable config is exit 2, never a silently widened scope. Qodo's suggested fix — carrying per-claim directory context out of the PR body — does not work: Dependabot dedupes a package across directories, so a grouped body states each bump once regardless of how many directories it touches. Lock files stay evidence-only, never grounds for failure. A legitimate single-directory PR leaves the other directories' lock files recording the old transitive version (#93 changed only Daqifi.Avalonia/), so failing on that would reject good PRs. Re-verified against the repo's real Dependabot PRs: passes #93/#95/#96, fails #130 on all ten unapplied claims, and the scope correctly excludes the iOS head. Self-test grows to 28 cases, including Qodo's exact scenario. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tylerkron
added a commit
that referenced
this pull request
Aug 31, 2026
…pped (#137) * chore(deps): make Daqifi.Core updates visible instead of silently skipped Daqifi.Core sat at 1.3.0 for five weeks while four releases shipped, and nothing said so. The assumption was that Dependabot had never opened a PR for it. It had — twice — but never in a way anyone could see: #93 bumped Core 1.3.0 -> 1.4.0, titled "the minor-and-patch group with 3 updates"; Core appears nowhere in the title. #95 superseded it with 1.3.0 -> 1.5.0, titled after Avalonia. 08-17 Dependabot auto-closed #95 and opened no replacement. Two weeks of silence while 1.6.0 and 1.7.0 shipped. #130 announced Core 1.3.0 -> 1.7.0 in its body and never touched the csproj. Ten of its fourteen announced updates are missing from the diff. The NU1605 downgrade theory does not explain it: Core 1.4.0/1.5.0/1.6.0 all depend on System.IO.Ports 10.0.10, exactly what was pinned. Only 1.7.0 raised the floor. Three guards, one per failure: - Daqifi.Core is excluded from the minor-and-patch group, so it always gets its own "Bump Daqifi.Core from X to Y" PR — visible in a PR list, and not droppable from a group whose other members moved. - check_dependabot_claims.py fails a Dependabot PR whose body claims a bump its manifests do not show. Verified against this repo's history: passes #93/#95/#96, fails #130 on all ten unapplied claims. - check_core_drift.py compares the pin against nuget.org weekly and files a rolling issue, independent of Dependabot having done anything at all. Both guards ship with self-tests, and build.yml now runs every .github/scripts self-test on each push and PR — without that, these two would only be exercised on a Dependabot PR or on a Monday. .github/dependency-updates/README.md records the investigation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): count lock files as evidence a claimed bump landed check_dependabot_claims.py only looked at .csproj PackageReference pins, so a transitive-only update — a security bump to something no csproj names — would have failed the check. That is the most costly PR to block on a false positive. Lock files are safe to trust here: in #130 the lock file recorded Daqifi.Core at 1.3.0 right alongside the csproj, because the bump landed nowhere. Re-verified against the repo's real Dependabot PRs — still passes #93/#95/#96, still fails #130 on all ten unapplied claims. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): check a claimed bump in every project that pins it, not just one Qodo, correctly: accepting a claim because SOME manifest reached the new version lets a grouped multi-directory PR move one head and leave another stale. Avalonia.Fonts.Inter is pinned by three projects here, so that is a real input shape, not a hypothetical. Now every project pinning the package must be at the claimed version — scoped to the `directories` Dependabot actually manages, read from dependabot.yml at check time. The scope matters in both directions: the iOS head is not managed, so its pins drift on purpose and must not fail a PR that could never have touched them; and if the list grows later, the check grows with it. An unreadable config is exit 2, never a silently widened scope. Qodo's suggested fix — carrying per-claim directory context out of the PR body — does not work: Dependabot dedupes a package across directories, so a grouped body states each bump once regardless of how many directories it touches. Lock files stay evidence-only, never grounds for failure. A legitimate single-directory PR leaves the other directories' lock files recording the old transitive version (#93 changed only Daqifi.Avalonia/), so failing on that would reject good PRs. Re-verified against the repo's real Dependabot PRs: passes #93/#95/#96, fails #130 on all ten unapplied claims, and the scope correctly excludes the iOS head. Self-test grows to 28 cases, including Qodo's exact scenario. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): measure Core drift from the oldest pin, not the first one read Same class of bug Qodo found in the sibling guard: check_core_drift.py returned the first manifest pinning Daqifi.Core and stopped. Two projects pinning it at different versions would report whichever happened to be read first — which could report "up to date" while another project sat four releases back. Drift is now measured from the oldest pin, with disagreeing pins called out explicitly, and the verdict no longer depends on manifest order. Today only Daqifi.Avalonia.csproj pins Core, so this changes nothing about the current repo; it stops the guard going quiet the moment that is no longer true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * style(ci): early-continue the lock-file walk instead of a wide ternary Drops a 92-character line to within the file's own width; no behaviour change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): keep every Daqifi.Core reference, not one per project file Qodo, correctly: pinned_versions keyed by manifest path, so a second reference to the package in the SAME project overwrote the first. Conditional ItemGroups per framework or RID are an ordinary MSBuild shape, and since drift is measured from the oldest pin, a newer reference could hide an older one and report the repo current while a conditional pin sat four releases back. It now returns every (version, manifest) pair. Ties resolve by manifest name rather than filesystem order, so the reported file is stable across runs. check_dependabot_claims.py does not share this: it keeps a set of versions per package per file, so a duplicate reference at a stale version already fails the claim. Tests cover both orderings of a doubly-referenced project — the verdict must not depend on which reference is read last. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
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.
Updated Avalonia.Controls.DataGrid from 12.1.0 to 12.1.2.
Release notes
Sourced from Avalonia.Controls.DataGrid's releases.
12.1.2
What's Changed
ClipboardContentBindingby @MrJul in Inherit DataType for ClipboardContentBinding AvaloniaUI/Avalonia.Controls.DataGrid#257LargeChangesynchronization by @zrt2399 in Fix DataGrid vertical scrollbar LargeChange synchronization AvaloniaUI/Avalonia.Controls.DataGrid#255Full Changelog: AvaloniaUI/Avalonia.Controls.DataGrid@12.1.0...12.1.2
Commits viewable in compare view.
Updated Daqifi.Core from 1.3.0 to 1.4.0.
Release notes
Sourced from Daqifi.Core's releases.
1.4.0
Verified end-to-end against a DAQiFi Nyquist (firmware 3.7.2) over USB: serial discovery, connect + populated init, 100 Hz streaming, SD card list/storage, and LAN chip info all pass. Full unit suite green (2,531 tests) on net9.0 and net10.0.
Highlights
IAsyncDisposable— connect and teardown now honor aCancellationToken, and devices can beawait using'd. (#341, #416)Features
DeviceCapabilitiesmerges the device's own live capability document, so what a device reports wins over compiled-in assumptions. (#390, #404)SendFailedevent instead of vanishing. (#413)Reliability & fixes
ConnectionStatus.Lostreachable. (#403)DeviceNotConnectedException. (#395, #402)ResetAllsemantics, and theVerifyingoverload. (#398, #405)LISTis no longer reported as an empty card. (#396, #400)IsEnabledtracks the device — protobuf field 22 is parsed. (#409, #411)Internal
DaqifiStreamingDeviceandFirmwareUpdateServicesplit into focused collaborators. (part of #344, #419, #422)Full Changelog: daqifi/daqifi-core@v1.3.0...v1.4.0
Commits viewable in compare view.
Updated SQLitePCLRaw.bundle_e_sqlite3 from 3.0.4 to 3.0.5.
Release notes
Sourced from SQLitePCLRaw.bundle_e_sqlite3's releases.
3.0.5
Update the lib dependency for
SQLitePCLRaw.bundle_e_sqlite3to package IDSQLiteversion 3.53.4.Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions