这不像新版本，新版本仍然具有向后兼容性。
我的意思是，当 C#、.NET、CLR 的设计者意识到他们犯了一个错误或者他们忽略了一些可能非常有益但现在由于向后兼容性而无法追求的东西时，他们可以通过以不同的方式(水平版本控制)指定它来分支适当的产品。
这不是更适合 future 吗？
你可以说这将是一场噩梦，但会有一些限制，比如你不能混合和匹配不同的分支，不像不同的语言相互兼容，等等(在同一个分支中)。
这样你会说使用 C# 4.0，那么你可以从 C# 4.0 B1(分支 1)中使用一些非常有用的东西，并且只使用它，即使它可能需要一些移植工作。
这不是一个健康的开发策略吗，新项目总是可以开始使用最新和最好的，即特定语言的最新版本和最新分支(例如 C# 6.0 B4)？
我看不出有任何额外的麻烦来跟踪新语言的事情，因为无论如何您已经必须了解每个版本的事情。所以这只是为垂直版本控制添加了另一个维度(水平版本)。
此开发策略的潜在优点/缺点是什么？
最佳答案
拥有大量可用于平台的库有很大的好处。目前，如果我编写 .NET 4.0 应用程序，我可以引用在 .NET 1.1 上创建的库。这意味着我可以利用大量现有代码，这是 .NET 的主要卖点之一。
如果我正确理解了您的建议，那么如果库 A 是针对 C# 4.0B1 编写的，而库 B 是针对 C# 4.0B2 编写的，那么我的应用程序无法编写为同时引用库 A 和库 B。这会使平台支离 splinter ，并且更难证明在编写 C# 应用程序或库方面的投资是合理的。
当然，也有与向后兼容性相关的成本(看看 Java 的泛型实现就知道了......)，但在我看来， yield 显然超过了它们。拥有一个使用某种语言或平台的充满活力的社区可以更轻松地聘请开发人员、找到具有有用功能的库、获得培训和支持等。这些网络效应都会因在平台内创建不兼容的孤岛而面临风险。
关于c# - 为什么 Microsoft 不对 C#、.NET、CLR 进行重大更改(水平版本控制)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3826661/