Directory.Build.props

<Project>

  <!--
    Shared multi-target framework list (#189).

    The four core shipped packages (Celerity.Collections / Celerity.Hashing /
    Celerity.Primitives / Celerity.Sorting), the test project, and the Native AOT
    smoke test all build for this same set of TFMs so they stay in lockstep — bump the list in
    one place and every shipped assembly and its verification follow.

    Why these three:
      - net8.0  — the prior single target; LTS (Nov 2023). Kept so existing
                  consumers are never dropped.
      - net9.0  — required by #189; STS (Nov 2024). Included for consumers still
                  on the 9.x line during the transition, even though its support
                  window is short.
      - net10.0 — GA Nov 2025, LTS, and the SDK the family already builds with.
                  Folded in now (the issue's "evaluate net10.0" decision) so
                  newer-runtime consumers get an assembly compiled against their
                  own reference pack, ready for future TFM-gated (#if) paths.

    Newer-runtime-only optimizations are guarded with #if NET9_0_OR_GREATER /
    NET10_0_OR_GREATER; the trim / AOT analyzers and the CS1591 doc gate run on
    every TFM. Dev-only, non-shipped projects (Celerity.Benchmarks,
    Celerity.Fuzz) deliberately stay single-TFM — they are tools, not packages.
  -->
  <PropertyGroup>
    <CelerityTargetFrameworks>net8.0;net9.0;net10.0</CelerityTargetFrameworks>
  </PropertyGroup>

  <!--
    Shared package-publishing settings (#190).

    These apply to every project under src/, but only the shipped packages are
    <IsPackable>true</IsPackable> — the test / benchmark / fuzz / AOT-smoke
    projects all set IsPackable=false, so the symbol-package and SourceLink
    settings below are no-ops there and only take effect on the shipped ones.
    Keeping them here (rather than duplicated in every shipped .csproj) is what
    makes the family release in lockstep: change a publishing rule once and every
    package follows.

    Symbol packages (.snupkg):
      IncludeSymbols + the snupkg format produce a separate symbol package per
      package next to each .nupkg, so `dotnet pack` emits Celerity.*.snupkg
      alongside Celerity.*.nupkg. Portable PDBs (the SDK default, pinned here for
      clarity) are required for the snupkg format and for SourceLink.

    SourceLink (debug-into-source):
      Since .NET 8 the SDK bundles the SourceLink host packages and enables them
      by default, so no explicit Microsoft.SourceLink.GitHub PackageReference is
      needed — it auto-detects the GitHub remote from the repo's git metadata.
      PublishRepositoryUrl stamps the repo URL into the package and the PDB;
      EmbedUntrackedSources embeds any generated/untracked sources so a stepping
      debugger can always resolve them.

    Deterministic builds:
      Deterministic is already the SDK default. ContinuousIntegrationBuild
      additionally normalizes embedded source paths (so the PDB/SourceLink paths
      are machine-independent and the build is byte-reproducible) — but it is
      turned on ONLY in CI, because normalized paths make a local F5 debugging
      experience worse. GitHub Actions sets both CI=true and GITHUB_ACTIONS=true.
  -->
  <PropertyGroup>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
    <DebugType>portable</DebugType>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <RepositoryType>git</RepositoryType>
    <Deterministic>true</Deterministic>
  </PropertyGroup>

  <PropertyGroup Condition="'$(ContinuousIntegrationBuild)' == '' and ('$(CI)' == 'true' or '$(GITHUB_ACTIONS)' == 'true')">
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
  </PropertyGroup>

  <!--
    Package validation — the binary-compatibility gate (#315).

    `dotnet pack` downloads each package's published predecessor and fails the
    build on any breaking change, across every TFM in the package. Without this,
    deleting a public member, narrowing a parameter type, or dropping a type
    forwarder produced a green CI run and a silently breaking package — and the
    push to NuGet.org is irreversible, so the guard has to run before it.

    Deliberate breaks are not blocked, only made explicit: run
    `dotnet pack -p:ApiCompatGenerateSuppressionFile=true` on the offending
    project, which writes a CompatibilitySuppressions.xml next to its .csproj.
    Commit it with a comment per entry so the break is reviewed in the PR.

    ### AT RELEASE TIME ###
    Bump CelerityPackageValidationBaseline below to X.Y.Z in a follow-up commit,
    once vX.Y.Z is published and indexed on NuGet.org. It must NOT move in the
    release commit itself: the value becomes a PackageDownload, so pointing it
    at a version that is not published yet fails the release build's restore.
    This is the part that rots: a stale baseline silently validates against an
    older surface, so a break introduced after it goes unnoticed. The ritual is
    written up in CONTRIBUTING.md, section "Cutting a release".

    All seven shipped packages (Celerity.Collections / Celerity.Hashing /
    Celerity.Primitives / Celerity.Sorting / Celerity.Ring / Celerity.Sentinel /
    Celerity.Cardinality) are published at this baseline and share it. A brand-new package has no
    published predecessor to validate against, and asking for one fails the
    restore, so its .csproj sets CelerityNoPublishedBaseline to true until its
    first release ships, then drops the property.

    Only the baseline version lives here, so there is exactly one line to bump.
    Turning validation on has to happen later, in Directory.Build.targets, where
    IsPackable is known; see the comment there.
  -->
  <PropertyGroup>
    <CelerityPackageValidationBaseline>2.5.0</CelerityPackageValidationBaseline>
  </PropertyGroup>

</Project>