为什么 Microsoft 不对 C#、.NET、CLR 进行重大更改（水平版本控制）分支？

Question

这与新版本不同，新版本仍然具有向后兼容性。

我的意思是，当 C#、.NET、CLR 的设计者意识到他们犯了一个错误，或者他们忽略了一些可能非常有益的东西但现在由于向后兼容性而无法追求它时，他们可以通过以不同的方式（水平版本控制）指定适当的产品来分支相应的产品。

这不是更具前瞻性吗？

你可以说这将是一场噩梦，但是会有一些限制，比如你不能混合和匹配不同的分支，不像彼此兼容的不同语言等（在同一个分支中）。

这样你会说使用 C# 4.0，那么你可以从 C# 4.0 B1（分支 1）中使用一些非常有益的东西并直接使用它，即使它可能需要一些移植工作。

这难道不是一个健康的开发策略，新项目总是可以开始使用最新最好的，即特定语言的最新版本和最新分支（例如 C# 6.0 B4）？

我看不出有任何额外的麻烦来跟踪新语言的内容，因为无论如何您都必须了解每个版本的内容。所以这只是为垂直版本增加了另一个维度（水平版本）。

此发展战略的潜在利弊是什么？

Answer 1

拥有大量可用于平台的库有很大的好处。目前，如果我编写一个 .NET 4.0 应用程序，我可以引用在 .NET 1.1 上创建的库。这意味着我可以利用很多现有代码，这是 .NET 的主要卖点之一。

如果我正确理解了您的建议，那么如果库 A 是针对 C# 4.0B1 编写的，而库 B 是针对 C# 4.0B2 编写的，那么我的应用程序就不可能同时引用库 A 和库 B。这将使平台碎片化，并且更难证明投资于编写 C# 应用程序或库的合理性。

当然，向后兼容性也有相关的成本（只要看看 Java 的泛型实现就知道了……），但在我看来，好处显然超过了它们。拥有一个使用语言或平台的充满活力的社区可以更轻松地雇用开发人员、找到具有有用功能的库、获得培训和支持等。这些网络效应都因在平台内创建不兼容的孤岛而面临风险。

Answer 2

实际上，这有点像开源批评者曾经争论开源项目最终会走向的方式。毕竟，你、我或其他任何人都可以在明天将任何开源项目分叉到不同的分支中。

值得庆幸的是，这会在社区中获得任何关注的唯一情况是，我们要么将其纳入专家角色（因此它并没有真正与原始项目竞争，只是建立在一个共同的祖先之上） ，或者对原始项目的运行方式有很大的不满（在开源政治中它是一种核打击选项）。

它被用作反对开源的妖魔论据的原因是，不可能跟踪给定库、框架、语言、组件等的哪个版本的哪个版本的哪个版本的哪个版本。可以使用哪个版本的哪个版本的哪个版本的另一个版本。

幸运的是，无论是开放的还是关闭的，这些分支机构都会在“市场”（无论该市场是经济市场还是其他市场）面前自然死亡。

Answer 3

许多（较大的）商店很难跟上已经发布的 .Net 主要修订版。这种策略可能适用于不是全球主要开发平台的平台，但对于微软（和许多开发人员）来说，这将是地狱。

Microsoft 非常重视向后兼容性，尤其是在关注开发人员（自 90 年代中期 Windows 起飞以来公司的命脉）方面。由于 Windows 的规模以及后来 .Net 的采用，重大更改具有不可知的影响。你想成为那个不得不向史蒂夫鲍尔默解释为什么你在新的小版本.Net中的酷修复破坏了通用电气（比如说）运行他们业务的应用程序的人吗？为了确保遗留应用程序和设备能够继续运行，我们付出了巨大的努力。增加要测试的版本矩阵不可避免地会导致偷工减料，我们都知道接下来会发生什么，对吧？

您可以反驳说，没有人必须采用最新的。但是这里谁不安装Windows SP，以避免安全问题的修补程序滴水？人们自然倾向于想要最新的，尽管这必须与稳定性问题保持平衡。

.Net 已经很好地从 Windows 开发人员词典中删除了 DLL 地狱，并且在某种程度上将开发人员平台的发展与操作系统版本分离。我认为大多数 Windows 开发人员并不急于看到这种变化。爱他们或恨他们，Microsoft 非常擅长管理仍然是世界事实上桌面标准的大型、不经常发布的版本。看看谷歌如何处理同样的问题将会很有趣，因为 Android 在未来一两年内会在移动市场上占据一席之地。