Name the version under development, and stop stamping 0.1.3.0 - #807
Merged
Conversation
Three fields disagreed with each other and with what shipped.
`Package.Build.props` still said `1.4.0-preview.4` although 1.4.0 was
released in January. Nothing published was wrong -- the NuGet workflow packs
with `-p:PackageVersion` taken from the release tag -- but a local build and
the assembly metadata carried the preview.
`AngouriMath.csproj` then overrode `AssemblyVersion` and `FileVersion` with
`0.1.3.0`, a number from long before 1.4. Because the override sat after the
props import it won, so `AngouriMath.dll` reported `0.1.3.0` while
`AngouriMath.FSharp.dll`, which has no override, reported `1.4.0.0`. The four
packages built from one repository did not agree on their own version.
Now the props carry it for all four:
Version 2.0.0-preview.1
AssemblyVersion 2.0.0.0
FileVersion 2.0.0.0
Measured on the built assembly rather than read off the diff:
AssemblyVersion 2.0.0.0
FileVersion 2.0.0.0
Informational 2.0.0-preview.1+21f0d16f
PublicKeyToken bccdab90849ccf86 (unchanged)
`AssemblyVersion` is pinned to the major for the whole of 2.x and deliberately
does not track `Version`. The assembly is strong-named, and for a signed
assembly every `AssemblyVersion` change breaks binding on a consumer that does
not add a redirect. Holding it at `2.0.0.0` makes each 2.x release a drop-in
replacement, and `FileVersion` carries the release for anyone reading the file
properties.
2.0 rather than 1.5 because the changes since 1.4.0 include ones no minor
version may carry: `Minusf.Minuend` and `.Subtrahend` exchanged names, so code
using them still compiles and now means the other operand; `Compile` over a
missing variable throws `UncompilableNodeException` where it threw
`KeyNotFoundException`; and `mod`, `floor` and ten other names that used to
parse as products now raise. BREAKING-CHANGES.md names the section for the
version it will ship as, and keeps saying it is unreleased.
5551 unit tests and 130 F# tests pass; all four packable projects build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three version fields disagreed with each other and with what actually shipped.
What was wrong
Sources/Package.Build.props1.4.0-preview.4Sources/AngouriMath/AngouriMath.csprojAssemblyVersion/FileVersion=0.1.3.0Nothing published was wrong —
Nuget.ymlpacks with-p:PackageVersiontaken from the release tag, so NuGet has always been named by the tag. But a local build and the assembly metadata carried these.Worse, they disagreed with each other. The csproj override sits after the
Package.Build.propsimport, so it won:AngouriMath.dllreported0.1.3.0whileAngouriMath.FSharp.dll, which has no override, reported1.4.0.0. Four packages built from one repository did not agree on their own version.Now
The props carry it for all four packable projects, and the csproj override is gone:
Measured on the built assembly rather than read off the diff:
Why
AssemblyVersionis pinned, and does not trackVersionThe assembly is strong-named (
SignAssembly,key.snk). For a signed assembly, everyAssemblyVersionchange breaks binding on any consumer that does not add a redirect. Holding it at2.0.0.0for the whole of 2.x makes each 2.x release a drop-in replacement;FileVersionand the informational version carry the actual release.Why 2.0 and not 1.5
The changes since 1.4.0 include ones no minor version may carry:
Minusf.Minuend/.Subtrahendexchanged names — code using them still compiles and now means the other operandCompileover a missing variable throwsUncompilableNodeExceptionwhere it threwKeyNotFoundExceptionmod,floorand ten other names that used to parse as products now raiseBREAKING-CHANGES.md's section is renamed to the version it will ship as, and still says unreleased — more is landing before the release.Not included, on purpose
AngouriMath.CPP.ExportingreferencesPackageReference AngouriMath 1.4.0-preview.2— it builds the C++ bindings against a published package rather than the source beside it, andCPPBuild/CPPTestrun on that. I verified it builds clean against aProjectReference, but that changes what code is compiled and tested rather than just metadata, so it belongs in its own PR where CPPTest can adjudicate it. Raised separately.Verification
5551 unit tests, 130 F# tests pass. All four packable projects build (AngouriMath,
.FSharp,.Interactive,.Terminal).🤖 Generated with Claude Code