Every CI job installed both 8.0.x and 10.0.x. Only two of them need the .NET 8 runtime: `unit-tests` and `static-code-analysis`, which both run the net8.0 leg of the multi-targeted test projects through `CodeCoverage`. Those keep it.
The rest never execute net8.0 code. `api-tests` runs `Awaiten.Api.Tests`, which targets net10.0 only; `benchmarks` runs a net10.0-only project; `aot-sample` publishes net10.0 natively; `web-sample` runs a net10.0-only app; `pack` builds every target framework but runs none of them, and building net8.0 needs only its reference pack, which restore supplies.
The GitVersion tool does not need it either, which is the part that looks like it should. Nuke runs `gitversion.dll` from the tool's `tools/net8.0` folder, but its runtimeconfig sets `rollForward: LatestMajor`, so the host starts it on whatever runtime is present. `publish-benchmark-report` has been running that way with only 10.0.x for some time, which is the standing proof.
So no change to the GitVersion pin or its `Framework`. Retargeting it to net10.0 would have required bumping the tool from 6.0.5 to 6.8.2, an eight-minor jump in the component that computes published package versions, in exchange for nothing.
Every CI job installed both 8.0.x and 10.0.x. Only two of them need the .NET 8 runtime:
unit-testsandstatic-code-analysis, which both run the net8.0 leg of the multi-targeted test projects throughCodeCoverage. Those keep it.The rest never execute net8.0 code.
api-testsrunsAwaiten.Api.Tests, which targets net10.0 only;benchmarksruns a net10.0-only project;aot-samplepublishes net10.0 natively;web-sampleruns a net10.0-only app;packbuilds every target framework but runs none of them, and building net8.0 needs only its reference pack, which restore supplies.