Why is the AssemblyVersion of Microsoft.Bcl.TimeProvider version 8.0.0.1 and not 8.0.1?

[MagicAndre1981]

In PR #94459 the ServicingVersion was set to 1 but compared to other packages where ServicingVersion number is the 3rd part of the version, here it is the 4th part of the version:

But the ProducVersion is 8.0.1 + hash (8.0.1+bf5e279d9239bfef5bb1b8d6212f1b971c434606)

Is this by design?

[huoyaoyuan]

The file version, assembly version and NuGet package version are completely independent numbers. They follow different contracts to satisfy different requirements.

but compared to other packages where ServicingVersion number is the 3rd part of the version

Those are NuGet package versions, which follows SemVer.

/cc @dotnet/area-infrastructure-libraries

[MagicAndre1981]

thanks for that information. Why don't all dotnet libs follow SemVer version schema? @ViktorHofer (you marked it as answer, can you explain this?)

[huoyaoyuan]

Why don't all dotnet libs follow SemVer version schema?

There's no difference between particular dotnet libs.

Assembly version is 4 int16 digits and respected by CLR assembly loader. It's incompatible with SemVer which use strings, and originates much earlier.