这与新版本的版本不同，新版本仍具有向后兼容性。
我的意思是这样的，当C＃,. NET，CLR的设计者意识到他们犯了错误或他们忽略了一些可能非常有益的东西但现在他们因为向后兼容而无法追求它时，他们可以分支适当的产品说，例如通过以不同的方式指定它（水平版本）。
这不会更具未来性吗？
你可以说这将是一场噩梦，但是会有一些限制，比如你不能混合和匹配不同的分支，而不是彼此兼容的不同语言等（在同一分支中）。
这样你会说使用C＃4.0，那么你可以使用C＃4.0 B1（分支1）并使用它，即使它可能需要一些移植工作。
这不是一个健康的发展策略，新项目总是可以开始使用最新版本和最新版本，即最新版本和特定语言的最新分支（例如C＃6.0 B4）？
我没有看到任何额外的麻烦来跟踪新语言的事情，你必须知道每个版本的事情。所以这只是为垂直版本添加了另一个维度（水平版本）。
这项发展策略的潜在利弊是什么？
答案 0 :(得分：2)
为平台提供大量库可以带来巨大的好处。目前，如果我编写.NET 4.0应用程序，我可以引用在.NET 1.1上创建的库。这意味着我可以利用很多现有代码，这是.NET的主要卖点之一。
如果我正确理解您的提议，那么如果库A是针对C＃4.0B1编写的，而库B是针对C＃4.0B2编写的，那么我的应用程序无法编写以引用库A和库B.这会破坏平台，使得编写C＃应用程序或库的投资变得更加困难。
当然，还有与向后兼容性相关的成本（看起来只是Java的泛型实现...），但在我看来，它的好处明显超过它们。拥有一个使用语言或平台的充满活力的社区，可以更容易地聘请开发人员，找到具有有用功能的库，获得培训和支持等。通过在平台内创建不兼容的岛，这些网络效应都会受到威胁。
答案 1 :(得分：1)
实际上，这有点像开源批评者用来争论开源项目最终会走的方式。毕竟，你，我或其他任何人都可以参加任何开源项目并明天将其分成不同的分支。
值得庆幸的是，这是唯一可以在社区中获得牵引力的情况，我们要么将其带入专业领域（因此它并没有真正与原始项目竞争，只是建立在共同的祖先之上） ，或者对原始项目的运行方式存在巨大的不满（在开源政治中它是一种核打击选项）。
它被用作反对Open Source的bogeyman论证的原因是，无法跟踪哪个版本的哪个版本的哪个版本的给定库，框架，语言，组件等版本的版本。可以使用哪个版本的哪个版本的哪个版本的哪个版本的哪个版本。
幸运的是，无论是公开还是封闭，这些分支机构都会在“市场”（无论该市场是经济市场还是其他市场）面前自然死亡。
答案 2 :(得分：1)
许多（较大的）商店在跟上已经出现的.Net主要版本时遇到了足够的麻烦。这种策略可能适用于不是全球主流开发平台的平台，但对于微软（以及许多开发人员）而言，这将是地狱。
微软非常重视向后兼容性，尤其是开发人员（自90年代中期以来Windows公司的生命线）受到关注。由于Windows的规模，以及后来的.Net，采用，突破性变化具有不可知的影响。你想成为那个必须向史蒂夫鲍尔默解释为什么你在.Net的新次要版本中的酷解决方案打破了通用电气（比如说）开展业务的应用程序的人吗？为确保传统应用和设备继续运行，我们付出了巨大的努力。增加要测试的版本矩阵将不可避免地导致角落被削减，我们都知道接下来会发生什么，对吗？
你可以反驳说，没有人必须采用最新的。但是，这些人出现时不会安装Windows SP，以避免因安全问题而导致安装修补程序？尽管必须与稳定性问题保持平衡，但人们仍然倾向于想要最新的。
.Net已经成为从Windows开发人员词典中删除DLL地狱的好方法，并且在某种程度上将开发人员平台进程从操作系统版本中分离出来。我不认为大多数Windows开发人员都急于看到这种变化。爱他们或恨他们，微软已经非常擅长管理仍然是世界上事实上的桌面标准的大型，不经常发布的版本。看看谷歌如何管理同样的问题会很有趣，因为Android会在未来一两年内在移动市场占据这一位置。