我们应该如何对附加包进行语义版本化

Question

我已经阅读了语义版本控制，但它没有提到我们应该如何处理附加包。

对于附加包，我指的是扩展主包的包，但不必与主包一起提供。包命名约定通常为<main>-<addon>，例如maven-war-plugin。

假设主页是pkg，版本为1.5，我们有一个名为pkg-dothis的附加包。我想要实现的是附加包的版本应该表明：

1. 与pkg 1.5兼容
2. 它能够显示新功能（它有自己的次要版本）
3. 它能够显示错误修复版本（它有自己的错误修复版本）

是1.5。<次要>lt；错误修复>足够好吗？

编辑：Rolf Rander建议我不应该使用"子包"这个词，所以我认为"附加组件"的误导性较小。

Answer 1

您对子包的定义并不完全清楚。如果包X依赖于包A、B和C，它是的子包吗？我想你最好不要用"一揽子计划"这个词。试图在版本号中表达依赖关系管理可能会导致以后出现问题。如果pkg-dothis与几个版本的pkg兼容怎么办？

Answer 2

这一切都取决于社区的期望。

maven社区似乎并不太关心匹配主包版本。所以您可以忽略主程序包版本。

另一方面，KDE社区的附加应用程序至少要匹配前两个版本号1。在这些社区中，如果附加组件更新样式或多或少类似于主包，也就是说，每当主包发布时，您都会进行相应的修改并使用主包中的新功能，那么您可以简单地使用KDE版本控制。也就是说，要么匹配主软件包，要么使用自己版本的补丁级别（第三个数字）。

如果新的功能更新可能挤入主包的次要更新之间，那么<主要专业><主要次要><addon minor><addon bugfix>似乎是一种合理的方式。