核心库和扩展库的版本控制答案

【问题标题】：Versioning for Core Library and Extension Libraries核心库和扩展库的版本控制
【发布时间】：2011-08-12 21:51:10
【问题描述】：

Ninject 项目由 Ninject 核心库和大量 (~17) 扩展库组成。

目前，Ninject 及其扩展库都具有相同的 Major.Minor 编号。 Ninject 内核的下一个版本将向后兼容，因此增加次要编号是正确的操作。至少有一个扩展库将不向后兼容。在这种情况下，正确的做法是增加主要号码。但这会使核心和扩展不同步。

问题是您认为哪个选项最容易引起混淆：

或者你能想到另一个更好的选择吗？

【问题讨论】：

我认为Software Engineering 更适合这个问题，但我想问你的是：你认为核心库的版本号与扩展的版本号密切相关吗？ ?
有问题的扩展库是否发生了变化？如：该扩展库中的代码是否发生了变化？
这些扩展通常是为最新的核心版本构建的，并使用一些新功能，因此不能与旧版本一起运行。另一方面，旧的扩展应该与更新的核心版本一起运行，只要它向后兼容。
一些扩展改变了但向后兼容，一些改变了破坏兼容性，一些没有改变。
我想我的主要问题是：如果只有核心 NInject 库发生了变化，并且您说它向后兼容，那么就没有办法对其进行扩展成为由于更新的核心库不兼容（这就是向后兼容的意思），除非该扩展名也发生了变化。因此，如果您在项目方面将扩展紧紧地绑定到核心，那么您将拥有相当强的依赖关系，您将努力摆脱它。

【解决方案1】：

我会选择最后一个选项，我不认为增加主要版本号意味着向后兼容性已被明确破坏，在很多情况下，产品的版本号增加而没有破坏向后兼容性，采取以 .NET 为例，多年来，版本号从 1 增加到 4，几乎所有版本都没有损坏。

【讨论】：