CSharpExtender.csproj does not enable package validation at all. ArgumentParser does, and its csproj is the working example.
This package is a large public API surface that a handful of Scott's other projects consume, and 3.0.0's release notes list twenty-odd breaking changes. Several of those were deliberate; the point of validation is catching the ones that are not.
Once 3.0.0 is on nuget.org, add:
<EnablePackageValidation>true</EnablePackageValidation>
<PackageValidationBaselineVersion>3.0.0</PackageValidationBaselineVersion>
dotnet pack then downloads 3.0.0 from nuget.org and fails the pack if a later 3.x removes or changes a public member. That turns "is this a breaking change?" from something to remember into something the build answers.
An intended break at 4.0.0 is handled by moving the baseline to the last 3.x, not by deleting the property.
Do not add the baseline before 3.0.0 ships. A baseline of 2.2.0 would fail the pack on every break the 3.0.0 notes already document.
Blocked until 3.0.0 is published (#115).
CSharpExtender.csprojdoes not enable package validation at all. ArgumentParser does, and its csproj is the working example.This package is a large public API surface that a handful of Scott's other projects consume, and 3.0.0's release notes list twenty-odd breaking changes. Several of those were deliberate; the point of validation is catching the ones that are not.
Once 3.0.0 is on nuget.org, add:
dotnet packthen downloads 3.0.0 from nuget.org and fails the pack if a later 3.x removes or changes a public member. That turns "is this a breaking change?" from something to remember into something the build answers.An intended break at 4.0.0 is handled by moving the baseline to the last 3.x, not by deleting the property.
Do not add the baseline before 3.0.0 ships. A baseline of 2.2.0 would fail the pack on every break the 3.0.0 notes already document.
Blocked until 3.0.0 is published (#115).