我正在为以下情况寻求指导-
假设我们具有以下公共API的多个生产版本-
1.1.0
2.1.2
如果在“ 1.1.0”版本修复中发现了一个错误/缺陷，将引入重大的非向后兼容更改，那么如何处理版本控制？在semver之后，重大更改将需要增加主版本-因此“ 1.1.0”应变为“ 2.0.0”。但是，我们已经有了下一个主要版本“ 2.1.2”，并对其进行了更改。
是否建议在主要版本升级之间跳过数字以适应此类情况？即“ 1.0.0”之后的下一个计划的主要版本应该是“ 3.0.0”？
还有其他建议吗？
答案 0 :(得分：0)
因此“ 1.1.0”应变为“ 2.0.0”
不是。 semver规范不仅已经具有2.0.0，而且不需要单调性。您可以将其发布为3.0.0或100.0.0。但是，通常在这里，您将停止对1.y.z系列的支持，并鼓励人们升级到您现有的2.y.z。
另一种选择是将1.0.0和2.0.0的功能集合并到3.0.0中。
附录：
您过去做出过某些选择，这些选择会影响品牌产品的未来发展以及您作为组织的声誉。当您声称要应用语义版本控制时，一定不要在不增加主版本号的情况下发布重大更改。您遵守指定语义的时间越长，客户就越会信任您的主张。
在这种情况下，您没有与标准机构签订任何合同，但是除此之外，我们这里的任何人都无法就您目前对客户的法律义务提供建议。此时，由您决定严格遵守服务是否符合客户或组织的最大利益。
除非您与客户之间有任何合同义务，我建议您尽可能与他们保持透明。解释您的商标和版本控制难题，并对1.y.z产品重新命名，使其可以坚持使用语义版本控制。如果您有产品X，则将其重命名为X.Classic或类似名称。