我已阅读semantic versioning，但是，它没有提及我们应该如何处理附加软件包。
对于附加软件包，我的意思是扩展主程序包的软件包，但不需要主软件包。包命名约定通常是<main>-<addon>，例如maven-war-plugin。
假设主页面为pkg且版本为1.5，并且我们有一个名为pkg-dothis的附加软件包。我想要实现的是附加软件包的版本应该表明：
pkg 1.5 是1.5。＆lt; minor＆gt;。＆lt; bugfix＆gt;够好吗？
编辑：Rolf Rander建议我不要使用术语＆＃34;子包＆＃34;，所以我假设＆＃34;附加＆＃34;不那么误导了。
答案 0 :(得分：0)
您对子包的定义并不完全清楚。如果包X依赖于包A，B和C，它是一个子包？我认为你不会使用术语子包更好。尝试在版本号中表达依赖关系管理可能会在以后导致问题。如果pkg-dothis与多个版本的pkg兼容，该怎么办？
答案 1 :(得分：0)
这完全取决于社区的期望。
maven社区似乎并不太关心匹配主程序包版本。所以你可以忽略主包版本。
另一方面，KDE社区，附加应用程序预计至少匹配前两个版本号1。在这些社区中，如果附加更新样式或多或少类似于主程序包，也就是说，每当主程序包出来时，您都会相应地进行修改并使用主程序包中的新功能，然后您可以简单地使用KDE版本控制。也就是说，要么匹配主程序包，要么使用自己版本的补丁级别（第3个数字）。
如果新功能更新可能会挤入主程序包的次要更新之间，那么＆lt; main-major＆gt;。＆lt; main-minor＆gt;。＆lt; addon-minor＆gt;。＆lt; addon-bugfix＆gt;似乎是合理的方式。