在红宝石生态系统（甚至其他地方）内是否有功能（即我可以将其与bundler和rubygems一起使用）替代 SemVer ？
我对 SemVer （ MAJOR.MINOR.PATCH ）的问题在于它试图量化两个不兼容的东西：
PATCH 仍然很可能是一个突破性的变化，这使得它等于 MAJOR ，同时小于 MINOR ， MINOR 小于 MAJOR 。 这样：
PATCH == MAJOR && MAJOR > MINOR && MINOR > PATCH
这意味着PATCH＆lt;＆gt; MINOR在同一时间，这永远不可能是真的。
理想情况下，我希望有两个版本控制线 - 一个基于向后兼容性（例如无破损，可能难以察觉的破损（==补丁），破损）和一个基于改变大小（无视向后兼容性），一个人性化的版本控制线，如果你愿意的话。我希望能够同时使用它们。
（仅基于纯粹的基于向后兼容性的版本控制，只要操作系统通过编写＆＃34; hello world＆＃34;到操作系统，我就可以从＆＃34; hello world＆＃34;转到操作系统屏幕。）
例如为： 如果 H 代表人类友好版本控制，而 B 代表向后兼容性基于向后兼容性，那么我希望能够说：
答案 0 :(得分：5)
rubygems / bundler中没有支持两个不同的并行版本号，没有。
但是没有理由你必须使用semver。您只需要一个版本号。 Bundler和rubygems适用于任何版本号的表格＆＃39; x.y.z＆＃39;，甚至＆＃39; x.y＆＃39;或者＆＃39; x.y.z.a.b＆＃39;，其中所有组件都是数字。就功能而言，您可以使用一个版本号做任何您想做的事情。 （如果你使用字母而不仅仅是数字，rubygems可能会认为它表示一个'预发布'版本。但如果你坚持使用数字，你可以做任何你想做的事情。
在semver之前，许多人只是在他们感觉到它的时候增加了组件，当它看起来像是像一个重大的变化，或一个较小的变化，或一个微小的变化。您当然可以这样做 - 或使用任何其他系统来确定要应用的单个版本号 - 并且基础结构将正常工作。您的下游用户可能会也可能不会欣赏它。
我不确定你是否误解了semver。 Semver says重大变更必须是主要版本增量。如果＆＃34; PATCH仍然很可能是一个突破性的变化，虽然＆＃34;，那么你不是在做semver。根据semver的说法，一个突破性的变化必定是一个主要的版本。这不是因为偶然的错误，或者不了解semver，或者不愿意遵循它但想要说他们仍然关注它的人 - 但它是什么塞弗说。
事实上，semver说版本号应仅 关于兼容性，不关于＆＃39; size＆＃39;改变（无论是主观的＆＃39; bigness＆＃39;还是bytesize;你似乎在谈论字节大小的增量，我以前从未见过对版本号的解释）。向后突破的变化需要一个主要版本的凸起;没有向后突破的更改的新功能需要一个小版本凹凸;否则（没有新功能，没有向后突破的变化;所以基本上是错误修正或内部重构）补丁级别的颠簸。 Semver确实不尝试合并两个不兼容的东西 - 而是试图完全抛弃其中一个，它抛出了一个版本号代表＆＃34;变化大小的想法＆＃34 ;，它只代表兼容性。人们对此的抵制，是对semver的一些抵抗，是真的。
我不确定你的意思是什么＆＃34;潜在地不知不觉地突破了变化＆＃34;。 Semver说，一个突破性的变化是主要的版本颠簸，你不能把它称为补丁，如果它可能不知不觉地打破＆＃34;，我想这意味着只有一些人会注意到它和你是猜猜最赢的吗？ Semver对此类别没有兴趣。 Semver不允许您在补丁级别版本中发布重大更改，因为您决定它可能会不知不觉地破坏＆＃34; （也许你喜欢它？）。
版本控制和发布管理很难。它通常是维护者的痛苦和下游用户的痛苦之间的平衡。我怀疑创建两个独立的并行版本号会改善一些事情，而不仅仅是让任何人都感到困惑。我甚至不理解你的实施方式＆＃34;我不希望你下载它，但确实给我带来了你在H2.0线上做出的那些不间断的改进＆＃34; - 听起来你似乎想象每个版本上只有两个版本号，但实际上有两个完全不同的＆＃34;行＆＃34; 版本号？
好吧，我想你可以这样做，只是发布两个不同的宝石名称。 Widget_H和Widget_B，我猜？我猜你的回购中有两个不同的git分支？我不知道，我很难弄清楚你的思考如何可能被运用到一个系统中，甚至是假设的。看起来它会让维护者和下游用户都感到困惑 - 但是只使用两个不同的gem名称可以在rubygems / bundler生态系统中实现你想要的东西吗？
如果您还没有阅读semver spec，我会非常鼓励，所以您了解semver是什么并且不是。