Bump BlackwellSystems.Gcf from 0.2.1 to 1.0.0 - #3131
Conversation
--- updated-dependencies: - dependency-name: BlackwellSystems.Gcf dependency-version: 1.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
.NET
ReviewWhat this PR does. Bumps Consumer surface. The package is only used by the Darling MCP service:
All three consumed symbols ( What's good.
What needs attention.
Not a blocker on the diff itself. Once the lockfile is refreshed this looks good to me — maintainer decides. Generated by Claude Code |
|
Claude posting for Erik Darling This is red on then commit the lock files it rewrites. On a CRLF checkout that is Worth knowing while this sits: |
Restore in locked mode fails NU1004 when Directory.Packages.props moves a version and the lock file still pins the previous range.
|
Reviewed this Dependabot bump against the repo's review checklist (T-SQL style, Lite/Darling parity, correctness, security, performance). Scope: Only Lite/Darling parity: No drift risk — Correctness/compat: This is a major version bump (0.x → 1.0), which can carry breaking changes under semver even from a "1.0" release. The only consumer calls Security: No new transitive dependencies, no secrets/network/file/process surface changes — just a version bump and lockfile hash update. No issues found. Looks safe to merge. |
|
Reviewed. This is a clean, low-risk Dependabot bump — no source/T-SQL changes, only
No findings. Fine to merge once CI passes. |
|
Reviewed. This is a mechanical Dependabot bump (
Nothing to change here. |
Directory.Packages.props conflicted because #3130 bumped the AWS SDK versions in the same ItemGroup region. Resolved to the newer version of each package on both sides: AWSSDK.PI 4.0.100.12, AWSSDK.RDS 4.0.105.1, BlackwellSystems.Gcf 1.0.0. The lock file is generated, so it was resolved by regenerating it against the merged props rather than by choosing a side.
|
Reviewed. This is a mechanical Dependabot bump ( Notes:
No blocking issues found. |
…ix merged pull requests (#3213) * Record the CHANGELOG entries for thirty-one changes across twenty-five merged pull requests Applies the `[Unreleased]` entries for the pull requests merged to `dev` from #3150 (the previous batch) through #3203. Lanes do not edit `CHANGELOG.md` -- every one of them appends to the same block, so a per-PR edit conflicts with whichever sibling merges first -- and the entry text rides each PR's own description instead. This is the periodic commit that applies it. `CHANGELOG.md` only, 56 insertions and no deletions: 31 entries prepended inside `## [Unreleased]` (6 under `### Added`, 2 under `### Changed`, 23 under `### Fixed`), newest merge first within each section, plus the 25 link-reference definitions they need appended at the foot of the file. Nothing already in the block was edited, reworded or reordered. Three of the 28 pull requests in the range earn no entry, each on measured precedent rather than judgement: #3150 is the previous batch pass itself, and no batch pass -- #2260, #2980, #3150 -- is cited anywhere in the file; #3130 and #3131 are routine Dependabot bumps, and none of the six merged Dependabot pull requests in the repository's history is cited either. Two pull requests carried no entry text anywhere, so theirs are written from their descriptions: #3176 (`pg_index_bloat`'s measured block rate) and #3184 (the PostgreSQL target's permissions section). * Record #3205's entry, which arrived on the merged base mid-batch #3205 merged while this batch was assembled, so `origin/dev` was merged in rather than rebased and its entry lands on top. An entry omitted because it arrived mid-batch is how a backlog restarts, and the batch's purpose is to make `[Unreleased]` current at its own merged base. One entry under `### Changed`, newest merge first ahead of #3195's, plus its link-reference definition. #3205 has no other pull request in the range behind it. * Take #3164's and #3166's entries from the lane handoff files instead of the PR bodies The entry text does not only ride the PR description. #3150's own account of the previous batch says 11 of its 66 entries came from a lane's handoff file in `~/Documents/pm-issue-queue-inbox/inbox/` rather than the body, and three files there carry dedicated entry text inside this range: `3164-changelog-entry.md`, `3166-changelog-entry.md` and `3169-changelog-entry.md`. Searching only the bodies missed the first two. - **#3164** (PR #3176) is no longer written from the PR description. Its lane wrote a full entry, and that text is used verbatim: it carries the 1,036 blocks/s upper bound, the reason the decoupling #3153 deferred is unreachable, the declined command-deadline route, the census deliberately not restated at the new ceiling, and the mutation that caught nothing. `[#2997]` joins the definition block at its ascending position, which that text cites and the file did not define. - **#3166** (PR #3168, absorbed and superseded by #3178) had no entry at all. #3178 grouped it into its own citation with a one-line summary, but its lane wrote a separate entry for the census that took `HeaviestHourlyRefreshObservedCeilingSeconds` from 594 s to 896 s and inverted the watch-line ordering. It sits beside #3178's, on #3178's merge. - **#3191's entry** said "#3184 named four of the six". #3184 was squash-merged and the four-of-six state never reached `dev`; it was a commit inside that PR, corrected before merge. "shipped" in this file means merged, so the clause now says a commit in #3184, which is what the #3187 lane's own report establishes. `CHANGELOG.md` only, 60 insertions and no deletions against `origin/dev`: 33 entries (6 Added, 3 Changed, 24 Fixed) and 27 definitions. All 15 definition runs keep the ordering they had, 9 of 15 ascending before and after. * Use the staged #3184 entry text instead of one written from the PR description #3184's entry now exists, staged by the lane that did the work, so the batch no longer invents one. Used verbatim, in `### Fixed` where its author targeted it and for the reason they gave: the section did not merely lack detail, it asserted "One role covers every collector", which is false in the direction that fails silently and which an operator would act on. Their text carries what a description-derived entry could not: the `pg_read_all_data` grant is PostgreSQL 14+ and the pre-14 fallback the section gave was `GRANT SELECT` on a schema, which is not valid PostgreSQL at all; the six collectors that need an extension, four of which additionally need `shared_preload_libraries` and a server restart; and why `pg_index_bloat` is unaffected by any grant. Both figures are live pre-change store reads rather than estimates. The citation is `[#3184]`, the pull request, because the change has no issue behind it, and its definition uses the `/pull/` form. `CHANGELOG.md` only, still 60 insertions and no deletions against `origin/dev`.
1 participant
Updated BlackwellSystems.Gcf from 0.2.1 to 1.0.0.
Release notes
Sourced from BlackwellSystems.Gcf's releases.
1.0.0
First stable release of the GCF codec for .NET.
The public API is now committed under semantic versioning:
Gcf—EncodeGeneric/DecodeGeneric, graphEncode/Decode, delta encoding, session dedup, pack roots, and streaming.Symbol,Edge,Payload,DeltaPayload,GenericSet,GenericDeltaPayload,GenericOptions,ReanchorPolicy,GenericDeltaSession,OrderedMap,Session,StreamOptions,StreamEncoder.DecodeException,EncodeException.No wire-format or behavioral changes from v0.2.1. Verified against the shared conformance suite (281 fixtures) and the cross-SDK differential fuzz.
Zero runtime dependencies. Multi-targets
netstandard2.0andnet8.0(runs on .NET Framework 4.6.1+, Mono, Unity, and modern .NET).NuGet: https://www.nuget.org/packages/BlackwellSystems.Gcf/1.0.0
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 this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)