为了发布某些软件的几个不同版本的 RPM 包，我正在寻找一种方法来指定被视为“升级”的版本“编号”，并包括几个预发布版本的区分，例如（按顺序）：“2.4.0 alpha 1”、“2.4.0 alpha 2”、“2.4.0 alpha 3”、“2.4.0 beta 1”、“2.4.0 beta 2”、“2.4.0 release candidates”、“2.4.0 final”、“2.4.1”、“2.4.2”等等。
我遇到的主要问题是 RPM 认为“2.4.0”早于“2.4.0.alpha1”，所以我不能仅在最终版本号末尾添加后缀。
我可以尝试“2.4.0.alpha1”、“2.4.0.beta1”、“2.4.0.final”，这些都可以工作，但“发布候选版本”除外，因为它被认为晚于“2.4.0.final”。
我考虑的另一种方法是使用 RPM 版本号的“epoch:”部分（epoch: 前缀在主版本号之前考虑，因此“1:2.4.0”实际上早于“2:1.0.0”）。通过在 epoch: 字段中放置时间戳，所有版本都会按 RPM 的预期排序，因为它们的版本似乎随时间递增。但是，当同时在几个主要版本上发布新版本时，这种方法会失败（例如，2.3.2 在 2.4.0 之后发布，但它们的 RPM 版本是“20121003:2.3.2”和“20120928:2.4.0”，而 2.3.2 上的系统无法“升级”到 2.4.0，因为 rpm 将其视为旧版本）。在这种情况下，yum/zypper/etc 拒绝升级到 2.4.0，这就是我的问题。
我可以使用哪些版本号来实现这一点，并确保 RPM 始终认为版本号是有序的。或者如果不是版本号，RPM 打包中还有其他机制吗？
注 1：我想保留 spec 文件中的“Release:”字段，用于它的原始用途（针对同一版本的打包软件发布多个软件包，包括打包更改）。
注 2：这应该适用于主要发行版的当前生产版本，例如 RHEL/CentOS 6 和 SLES 11。但我对不涉及重新编译 rpm 的解决方案也很感兴趣！
注意 3：在类似 Debian 的系统上，dpkg 在版本号中使用特殊组件，即“~”（波浪符号）。这会导致 dpkg 将后缀计为“负”排序，因此“2.4.0~anything”将位于“2.4.0”之前。然后，在“~”之后应用正常排序，因此“2.4.0~alpha1”位于“2.4.0~beta1”之前，因为“alpha”按字母顺序位于“beta”之前。我不一定希望对 RPM 软件包使用相同的方案（我非常确定不存在这样的等效方案），因此这只是供您参考。
答案1
答案2
Fedora 有一套设置预发布软件包版本/发布号的指南。基本上，您使用 中最终版本的版本号，并以Version开头，然后是 ，一个递增的数字，或者其他任何数字。您根本不会使用字母数字标签来表示最终版本。Release0.alphabetafinal
请注意，您不能指望 RPM 支持 Debian 风格的波浪符号版本控制。多个发行版禁用此功能。
答案3
我不喜欢 alpha/beta 的区别。有已发布的代码和未发布的代码。
我的做法：我喜欢使用持续集成系统（参见 JenkinsCI）的 major.minor.build。构建整数永远不会重置。次版本号更改是为了向后兼容更改。主版本号更改是大事。
如果市场营销不喜欢将“版本”设为大整数，那么您可以仅在发布的版本中为市场营销增加一次次要编号，然后在进入工程设计时再次增加。
答案4
从 4.10.0 版本开始，RPM 正式支持问题中提到的 dpkg 样式波浪符号编号。