xyz> xyz-beta（またはalpha、rcなど）の増分RPMパッケージバージョン「番号」

一部のソフトウェアのいくつかの異なるバージョンの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リリース候補」、 「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：」セクションを使用することです（「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上のシステムは、rpmが古いバージョンと見なしているため、2.4.0に「アップグレード」できません。この場合、yum / zypper / etcは2.4.0へのアップグレードを拒否するため、問題が発生します。

これを実現するためにどのバージョン番号を使用できますか。また、RPMが常にバージョン番号が正しいと見なすようにしてください。または、バージョン番号でない場合、RPMパッケージの他のメカニズムは？

注1：仕様ファイルの「Release：」フィールドを元の目的（同じバージョンのパッケージソフトウェアについて、パッケージの変更を含む、パッケージのいくつかのリリース）のために保持したいと思います。

注2：これは、RHEL / CentOS 6やSLES 11などの主要なディストリビューションの現在の製品バージョンで動作するはずですが、rpmの再コンパイルが含まれない限り、動作しないソリューションにも興味があります！

注3：Debianのようなシステムでは、dpkgはバージョン番号に「〜」（チルド）文字である特別なコンポーネントを使用します。これにより、dpkgはサフィックスを「負の」順序として数えるため、「2.4.0〜anything」は「2.4.0」より前になります。次に、「〜」の後に通常の順序が適用されます。したがって、「alpha」は「beta」の前にあるため、「2.4.0〜alpha1」は「2.4.0〜beta1」の前に来ます。私は必ずしもRPMパッケージに同じスキームを使用するつもりはありません（そのような同等のものは存在しないと確信しています）。これは単なる参考です。

公式の回転数のガイドラインは、これを行う方法を教えてくれ、とへのリンク例ページ。これは、3つのレベルのプレリリース（a、b、rc）を使用する非常に一般的なバージョン管理スキームを使用する方法の例です（rpmにより、残念ながらサポートが若干複雑になります）。

• 1.0.0a1-> 1.0.0-0.1.a1
• 1.0.0b1-> 1.0.0-0.1.b1
• 1.0.0b2-> 1.0.0-0.1.b2
• 1.0.0b2、2番目のリリース（1.0.0b2のパッケージ化調整）-> 1.0.0-0.2.b2
• 1.0.0rc1-> 1.0.0-0.1.rc1
• 1.0.0-> 1.0.0-1
• 1.0.1a1-> 1.0.1-0.1.a1
• 1.0.1-> 1.0.1-1

Fedoraには、プレリリースパッケージのバージョン/リリース番号を設定するための一連のガイドラインがあります。基本的には、中に最終リリースがどうなるかのバージョン番号を使用しVersionて、開始Releaseと数0.、インクリメント数、そしてalpha、betaまたは何を。final最終リリースでは、英数字タグをまったく使用しません。

RPMがDebianスタイルのチルダバージョン管理をサポートしているとは限りません。いくつかのディストリビューションでは、この機能が無効になっています。

私はアルファ/ベータの区別のファンではありません。リリースされたコードとリリースされていないコードがあります。

方法：継続的インテグレーションシステムを備えたmajor.minor.buildが好きです（JenkinsCIを参照）。ビルド整数はリセットされません。マイナーバージョン番号の変更は、下位互換性のための変更です。大きな数字の変更は大きな問題です。

マーケティングで「ビルド」が大きな整数になりたくない場合は、リリースされたビルドでのみマーケティング用にマイナー番号を1度増やしてから、エンジニアリングに移行するときにもう一度増やすことができます。

私は同様の問題にぶつかり、RedHat、Debian、Pythonパッケージ、Ruby gemのリビジョンを比較してスイート番号を統一する必要がありました。これにより、それぞれの場合に「より大きい」と「より小さい」を評価するのに役立ちました。

これは、1.3.0.post0.dev20180213210433を1.3.0、YMMVと比較しています。

Red Hatの場合（https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparisonに感謝）

docker run -ti centos:7
yum install rpmdevtools.noarch
rpmdev-vercmp "1.3.0" "1.3.0.post0.dev20180213210433" 
1.3.0 < 1.3.0.post0.dev20180213210433

Debianの場合：

$ dpkg --compare-versions 1.3.0 gt 1.3.0.post0.dev20180213210433 ; echo $?
1  # false
$ dpkg --compare-versions 1.3.0 lt 1.3.0.post0.dev20180213210433 ; echo $?
0  # true

Pythonの場合

>>> from pkg_resources import parse_version
>>> parse_version("1.3.0") > parse_version("1.3.0.post0.dev20180213210433")
False
>>> parse_version("1.3.0") < parse_version("1.3.0.post0.dev20180213210433")
True

Rubyの場合

irb(main):001:0> Gem::Version.new("1.3.0") > Gem::Version.new("1.3.0.post0.dev20180213210433")
=> true
irb(main):002:0> Gem::Version.new("1.3.0") < Gem::Version.new("1.3.0.post0.dev20180213210433")
=> false

バージョン4.10.0以降、RPMは質問で言及されているdpkgスタイルのチルダ番号を正式にサポートしています。

https://rpm.org/wiki/Releases/4.10.0