关于语义版本控制

在“技术通过永久链接避免埋没”一节中，我将切入我的观点：SemantiVersioning是一个元API，对于违反它的维护人员来说，不能相信他们会创建稳定的合同。(#**$${##**$$})。我已经失去了打破改变的耐心，因为在我的代码库中，维护员没有递增他们项目的主要版本，特别是在期望进行语义版本控制的语言生态系统中，在这种情况下，我将开始探索替代选项，这样我就可以在我的项目中完全禁止这样的库-个人的和专业的-完全禁止这样的库出现在我的项目中-个人的和专业的-完全禁止这样的库出现在我的项目中-个人的和专业的-完全禁止这样的库。

当开发人员在他们的代码库中采用外部库时，他们知道他们在使用该库时会受到应用程序编程接口(API)的约束。从这个意义上说，API可以看作是图书馆的维护者和消费者之间的一种契约。如果维护人员频繁更改库的API，那么该API就被认为是不稳定的。在这种情况下，消费者要么无论如何都要使用图书馆，要么接受由于图书馆的改变而导致的东西被破坏的风险，或者他们会避免它。

语义版本控制试图通过在软件版本号中嵌入向后和向前兼容的概念来缓解这一局面。如果图书馆维护员坚持这样做，那么消费者就可以升级到图书馆的更新版本(比如，获取错误修复)，而不必担心破坏更改，前提是他们不会转移到新的主要版本。就向后兼容性和向前兼容性而言，SemancVersioning创建了一种预期，即给定版本的库与下一个主要版本之前的任何未来版本都是向前兼容的。库还可以向后兼容到最新的次要版本(如果使用者使用的是较新的库功能，则超过此版本的代码_可能_BREAK)。

使用语义版本控制有几个好处。一个好处是可以很容易地将依赖需求编码到自动化依赖工具中。通过假设语义版本控制，NodeJS的NPM和Rust的Cargo等工具的用户能够指定依赖范围，而不是硬编码的版本。因此，如果一个库的新版本发布，这些工具能够自动决定它们是否可以在给定的项目中使用。换句话说，语义版本控制为下游开发人员提供了一个机会，让他们可以轻松地决定是否升级到库的新版本，从而有可能在升级过程中获得重要的错误修复。

如果您在一个语言生态系统中工作，其中语义版本控制是事实上的规范，违反它可能会对下游造成严重破坏，那么请善待它并遵循它的指令。与其把它看作是一件风向标，不如试着把它看作是一种算法，来决定你的下一个版本号应该是什么。我们都应该喜欢算法！

如果你拒绝被说服，那就明白我不会在你的下游工作1。我会找一个不同的上游合作伙伴，因为我不相信你能签订一份稳定的合同。在我从事的任何项目中采用库之前，我会在将来考虑您是否愿意遵守meta-API。祝你一切顺利，希望你玩得开心，我一定会避开你的。

我在这里要指出的是，在语义版本控制不是事实规范的环境中，我会更宽容。