为什么 FSharp.Core.dll 的名称中不包含主要版本？

Question

为什么FSharp.Core.dll 的名称中不包含主要版本？对解决二进制兼容性问题没有帮助吗？

就我understand 而言，在创作用 F# 开发的库时，它应该依赖于 FSharp.Core.dll NuGet 包，版本上限为 <CurrentMajor+1。上版本不能不受约束，因为只有在具有相同主要版本的库之间才能保证二进制兼容性。只是一个semantic versioning 模型。

现在让我们想象一个有用的库，它没有错误并且逻辑完成。换句话说，不再需要支持它。期间。

然后 F# 5 发布并且......该库的用户不能再在引用使用 F# 5.x 创建的库的项目中使用它

---

好的，上面的说法是错误的
（对于F# 2、F# 3 和F# 4 FSharp.Core 库有版本4.x.y.z。）

尽管如此，问题仍然有效。

在某个时间点，主要版本将增加到5。据说这会破坏二进制兼容性。 （否则你为什么要增加呢？）

这就是我的意思：
项目参考NuGet.New 和NuGet.Old。
NuGet.Old 参考FSharp.Core.dll [4.x.y.z, 5.0.0.0)
NuGet.New 参考FSharp.Core.dll [5.0.0.0, 6.0.0.0)
NuGet 不允许。是版本冲突。

实际上我昨天（2018 年 12 月 4 日）遇到了类似的问题，当时 EF Core 2.2 NuGet 包已经可用，但 ASP.NET Core 2.2 的 SDK 没有。

Micrsofot.AspNetCore.App 元数据包将EF Core 的版本固定到[2.1.0, 2.2.0) 范围内。在我的DAL 项目中引用EF Core 2.2 后，由于版本冲突，整个解决方案停止构建。

---

但是，如果是 FSharp4.Core.dll 和 FSharp5.Core.dll，它们可以并肩工作。

是的，表示 F# 4.x 和 F# 5.x 相同概念的 CLR 类型的约定和形状可能不同，但编译器可以使用其主要版本标记类型。这不仅有助于区分新对象和旧对象，还可以允许新编译器静默创建代码以使旧类型适应新版本。

Answer 1

主要语言版本是包中的第一个数字和 F# 4.5 的二进制版本。

FSharp.Core 是二进制兼容的。在您的场景中，F# 5 的用户仍然可以使用旧库。不这样做将是一个错误。