使用通过 RPM 交付的产品进行发布周期
我刚刚开始第一次使用通过 Linux RPM 机制交付的产品，而不是作为独立安装程序，并意识到这使得测试/发布周期变得更加棘手。
当我与安装人员合作时，我们只需更改构建系统中的构建编号，将构建标记为测试或候选发布版本而不是开发快照，并告诉人们仅安装候选构建以进行测试。 使用 RPM 这样做的问题是，如果我们更改编号系统，我们将破坏交付机制，并且已安装的计算机将无法再辨别哪个是 RPM 的最新版本。
我想到的解决这个问题的最好方法是将候选 RPM 放在一个完全独立的 RPM 存储库中，但这也变得复杂，因为我们有多个 RPM 来自同一存储库，并且处于不同的发布周期，所以我们'您将尝试从新存储库中提取 RPM A 的候选发布版本，同时仍希望从开发存储库中获取 RPM B 的开发快照。
对于 Linux 软件来说，这肯定是一个非常常见的问题，所以有人可以告诉我最佳实践吗？ 提前致谢 .....
I just started working for the first time with a product that's delivered via the Linux RPM mechanism, rather than as a standalone installer, and realized that this makes the test / release cycle a bit more tricky.
When I was working with installers, we would just change the build numbering in our build system to mark a build as a test or release candidate instead of a development snapshot, and tell people to install only the candidate build for testing. The problem with doing that with RPMs is that if we change the numbering system, we'll break the delivery mechanism and installed machines won't be able to tell which is the latest version of the RPM any more.
The best way I've thought of to get around this is to put the candidate RPMs in a completely separate RPM repository, but this also gets complicated because we have multiple RPMs coming from the same repository that are on different release cycles, so we'll be trying to pull the release candidate version of RPM A from the new repository while still wanting to get development snapshots of RPM B from the development repository.
This must be a pretty common issue for Linux software, so can anyone tell me the best practice ? Thanks in advance .....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Linux 世界中的一种常见方法是采用广泛公开的版本号约定来指示构建是开发还是发布。 对于Linux内核本身，奇数点版本（2.5、2.7）是开发版本，而偶数点版本（2.4、2.6）是版本。
快速浏览一下 RPM 指南 似乎表明使用这样的方案可能是最好的选择。
One common methodology in the Linux world is to have a widely-publicized release number convention that indicates whether a build is development or release. For the Linux kernel itself, odd point releases (2.5, 2.7) are development, while even (2.4, 2.6) are releases.
A quick scan of the RPM guide seems to indicate that using a scheme like this may be the best bet.