是否有任何计划让ServiceStack软件包开始使用SemVer标准？我们刚刚遇到一个令人遗憾的情况，我们被破坏了4.0.44中从4.0.43围绕OrmLite引入的界面。
我们是一个相当大的商业客户，并为我们的一个DBMS定制了OrmLiteDialectProvider，在我们的Web应用程序初始升级时看起来都很好，但是作为测试类型转换的变化的一部分打破了我们的系统。这最初并不是升级的一部分，因为我们的自定义实现是在NuGet包中，它在版本4.0.38上覆盖OrmLiteDialectProvider.ConvertDbValue，现在已经不存在了。没有绑定问题，因为它只是一个小的版本差异。
NuGet adopted SemVer back in version 1.6
使用SemVer标准可以让我们更容易知道何时进行了界面破坏更改，而无需深入了解发行说明页面。
注意：该版本也没有表明旧方法已被删除，升级会破坏任何自定义实现。
响应更新
无论如何，公平的回答。我很高兴能够单独跟踪每个包裹。在我们的例子中，我们编写了一个自定义方言提供程序，因为我们有一个不受支持的遗留DBMS，这似乎是我们应该添加支持的方式。我们想使用ORMLite，因为我们使用ServiceStack的其余部分，它是一个很棒的产品。 支持这些类型的新方法是一个很大的改进，实际上使我们的实现更容易。
我们实际上遇到了这个问题，因为我们始终保持我们的ServiceStack软件包内联，并且正在升级ASP部分，以便对WSDL生成进行一些修复，这是我们升级的一部分。
答案 0 :(得分：2)
ServiceStack对所有共享相同版本号的NuGet包采用单一滚动版本。在所有ServiceStack的60个NuGet软件包中，至少有一个软件包可能会发生重大变化，因此semver将毫无用处，您也应该永远不要将不同版本的ServiceStack混合搭配 - 升级时，升级所有软件包以引用相同的软件包版本。我们的目标是将面向用户的重大变更保持在最低限度，方法是首先弃用旧API，维护并行API版本一段时间，然后列出新API的发行说明。
但是IOrmLiteDialectProvider不被视为面向用户的界面，因为任何人都应该实现自己的自定义提供程序的情况非常少见。它也是所有RDBMS专业化的接口，并且通常随每个版本而变化，以支持新功能，内部重构，优化等。实现Type Converters是一个主要的内部重构，需要更改IOrmLiteDialectProvider但不影响OrmLite的外部面向用户的API，后续版本包括需要进一步更改的优化，同样这不会影响OrmLite的外部用户面向API。
SemVer在这里没有帮助，每个ServiceStack版本都可能在某些软件包中发生重大变化，我们无意通过不同地对每个软件包进行版本化来使每个版本复杂化。您遇到的问题取决于不适合自定义的不稳定接口。它不被视为面向用户的API，因此我们不会尝试保持与现有版本的兼容性或发布几乎每次向OrmLite添加功能/优化时发生的重大更改。您应该检查commit history of IOrmLiteDialectProvider是否有对此界面的任何更改。