Policy: support only in-support .NET targets (breaking — batched to next yearly major)

[ChrisonSimtian]

v11 decision (2026-05-24)

Formalising the policy: Fallout packages target only .NET versions currently in Microsoft support. v11 is the breaking release that bakes this in — anything falling out of support gets dropped, no transition shims, no multi-targeting back-compat.

Today that means net10.0 only (net8 is in support until Nov 2026 but we are not multi-targeting back; consumers stay on net10 SDK to compile their build project — see below).

Pairs with #14 — the .NET 10 setup bug is part of the same release.

What v11 actually delivers under this policy

• Audit Directory.Build.props / per-project <TargetFramework(s)> and ensure nothing still references EOL TFMs.
• Codify the policy in CONTRIBUTING.md or a docs page so future PRs that add older TFMs get rejected at review.
• Communicate the breaking-release expectation in the v11 release notes / announcement.

---

Historical context (original ticket framing — demand-gathering)

Currently Nuke.Common (and sibling libraries) target net10.0 only, matching Matt's 10.0.0 release decision. Consumers must use a _build.csproj on net10.0 to reference the package.

This issue documents the deferred option to multi-target on net8.0 + net10.0 — taken intentionally for now, with this issue as the place to surface real demand if it materializes.

Why we chose single-target

Factor	Rationale
.NET 8 EOL	November 2026 — only ~6 months out. Multi-targeting would briefly reduce friction, then become baggage on an EOL framework.
Consumer impact	Only the _build.csproj TFM has to change in consumers — not their production code. The build orchestrator's TFM is independent of the app's TFM.
Maintenance	Single target = simpler dep matrix, no TFM-conditional code, smaller test surface.
Enterprise signal	"Stays on supported LTS" is the right message; multi-targeting near-EOL frameworks contradicts it.