Discussion from #312
@DanielBunting
DanielBunting
2 days ago
[Query] For the packages exposed by ClickHouse.Driver itself - specifically Microsoft.Extensions.* and System.Text.Json - is pinning to 10.0.5 intentional?
Since the library targets net6.0/net8.0/net9.0/net10.0, this forces consumers on older target frameworks to take a net10-era System.Text.Json/Microsoft.Extensions.* into their dependency graph even though nothing in the driver requires those APIs.
Would it make sense to either pin to the lowest supported version (e.g. 6.0.x) or use per target framework package version as such?
Test/benchmark/dev deps can stay on latest — this is just about the published package's public dependency surface.
Member
Author
@alex-clickhouse
alex-clickhouse
2 days ago
The main reasons against it:
It's a rather annoying maintenance burden.
10.x.x packages are fully compatible with every framework version.
And most importantly, versions 7-and-below are out of support, some of the packages have unpatched vulnerabilities (and even the 8.x.x hasn't been updated since August last year).
Does the benefit of users not having to update their dependencies outweigh that?
Contributor
@DanielBunting
DanielBunting
2 days ago
Fair points on maintenance burden; that's the real cost. A few things worth thinking about:
On compatibility: the 10.x packages load on older TFMs, but a net8.0 consumer ends up shipping System.Text.Json 10.0.5 alongside the in-box 8.x, which adds payload and can surprise trimmed/AOT scenarios. So there is a consumer-side cost beyond "does it run."
On security: pinning the floor low doesn't trap consumers on vulnerable versions - it lets their app float up to whatever they need. The current pin actually does the opposite: every consumer is forced onto exactly 10.0.5 until the driver ships a new release, so a future CVE found in 10.0.5 fans out to all of them.
On 8.x looking stale: 8.0.x is still in LTS servicing - patches land on the 8.0.x line by design rather than moving the major.
If the CVE concern is really about net6.0/net7.0 being EOL, would it be cleaner to drop those TFMs entirely? That solves the CVE concern without forcing the version on the still-supported net8.0/net9.0 consumers.
Happy to defer if maintenance burden tips the call though - your repo, your call.
Discussion from #312
@DanielBunting
DanielBunting
2 days ago
[Query] For the packages exposed by ClickHouse.Driver itself - specifically Microsoft.Extensions.* and System.Text.Json - is pinning to 10.0.5 intentional?
Since the library targets net6.0/net8.0/net9.0/net10.0, this forces consumers on older target frameworks to take a net10-era System.Text.Json/Microsoft.Extensions.* into their dependency graph even though nothing in the driver requires those APIs.
Would it make sense to either pin to the lowest supported version (e.g. 6.0.x) or use per target framework package version as such?
Test/benchmark/dev deps can stay on latest — this is just about the published package's public dependency surface.Member
Author
@alex-clickhouse
alex-clickhouse
2 days ago
The main reasons against it:
It's a rather annoying maintenance burden.
10.x.x packages are fully compatible with every framework version.
And most importantly, versions 7-and-below are out of support, some of the packages have unpatched vulnerabilities (and even the 8.x.x hasn't been updated since August last year).
Does the benefit of users not having to update their dependencies outweigh that?
Contributor
@DanielBunting
DanielBunting
2 days ago
Fair points on maintenance burden; that's the real cost. A few things worth thinking about:
On compatibility: the 10.x packages load on older TFMs, but a net8.0 consumer ends up shipping System.Text.Json 10.0.5 alongside the in-box 8.x, which adds payload and can surprise trimmed/AOT scenarios. So there is a consumer-side cost beyond "does it run."
On security: pinning the floor low doesn't trap consumers on vulnerable versions - it lets their app float up to whatever they need. The current pin actually does the opposite: every consumer is forced onto exactly 10.0.5 until the driver ships a new release, so a future CVE found in 10.0.5 fans out to all of them.
On 8.x looking stale: 8.0.x is still in LTS servicing - patches land on the 8.0.x line by design rather than moving the major.
If the CVE concern is really about net6.0/net7.0 being EOL, would it be cleaner to drop those TFMs entirely? That solves the CVE concern without forcing the version on the still-supported net8.0/net9.0 consumers.
Happy to defer if maintenance burden tips the call though - your repo, your call.