“Paket” versi paket RPM tambahan untuk xyz> xyz-beta (atau alpha, rc, dll)

Untuk menerbitkan paket RPM dari beberapa versi perangkat lunak yang berbeda, saya sedang mencari cara untuk menentukan versi "angka" yang dianggap "peningkatan", dan termasuk diferensiasi beberapa versi pra-rilis, seperti (dalam rangka ): "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", "kandidat rilis 2.4.0", "2.4.0 final", "2.4.1", "2.4.2", dll.

Masalah utama yang saya miliki dengan ini adalah bahwa RPM menganggap bahwa "2.4.0" datang lebih awal dari "2.4.0.alpha1", jadi saya tidak bisa menambahkan sufiks di akhir nomor versi final.

Saya bisa mencoba "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", yang akan berfungsi, kecuali untuk "kandidat rilis" yang akan dianggap lebih lambat dari "2.4.0.final ".

Alternatif yang saya pertimbangkan adalah menggunakan bagian "epoch:" dari nomor versi RPM (epoch: prefix dipertimbangkan sebelum nomor versi utama sehingga "1: 2.4.0" sebenarnya lebih awal dari "2: 1.0.0") . Dengan meletakkan stempel waktu di bidang epoch:, semua versi dipesan sesuai yang diharapkan oleh RPM, karena versi mereka tampak bertambah seiring waktu. Namun, ini gagal ketika rilis baru dibuat pada beberapa versi utama secara bersamaan (misalnya, 2.3.2 dirilis setelah 2.4.0, tetapi versi mereka untuk RPM adalah "20121003: 2.3.2" dan "20120928: 2.4. 0 "dan sistem pada 2.3.2 tidak dapat" ditingkatkan "ke 2.4.0, karena rpm melihatnya sebagai versi yang lebih lama). Dalam hal ini, yum / zypper / etc menolak untuk memutakhirkan ke 2.4.0, jadi masalah saya.

Nomor versi apa yang dapat saya gunakan untuk mencapai hal ini, dan pastikan bahwa RPM selalu menganggap nomor versi sebagai urutan. Atau jika bukan nomor versi, mekanisme lain dalam kemasan RPM?

Catatan 1: Saya ingin menyimpan "Rilis:" bidang file spesifikasi untuk tujuan aslinya (beberapa rilis paket, termasuk perubahan kemasan, untuk versi yang sama dari perangkat lunak yang dikemas).

Catatan 2: Ini harus bekerja pada versi produksi saat ini dari distribusi utama, seperti RHEL / CentOS 6 dan SLES 11. Tapi saya tertarik pada solusi yang tidak, asalkan tidak melibatkan kompilasi ulang rpm!

Catatan 3: Pada sistem seperti Debian, dpkg menggunakan komponen khusus dalam nomor versi yang merupakan karakter "~" (tilde). Ini menyebabkan dpkg menghitung akhiran sebagai urutan "negatif", sehingga "2.4.0 ~ apa pun" akan muncul sebelum "2.4.0". Kemudian, pemesanan normal berlaku setelah "~", jadi "2.4.0 ~ alpha1" datang sebelum "2.4.0 ~ beta1" karena "alpha" datang sebelum "beta" secara alfabet. Saya tidak perlu mencari untuk menggunakan skema yang sama untuk paket RPM (saya cukup yakin tidak ada yang setara seperti itu), jadi ini hanya FYI.

The pedoman rpm resmi memberitahu bagaimana melakukan ini, dan link ke halaman contoh . Berikut adalah contoh bagaimana Anda akan bekerja dengan skema versi yang sangat umum yang menggunakan tiga tingkat pra-rilis (a, b, rc) (yang sayangnya membuat rpm agak rumit untuk didukung):

• 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, rilis kedua (tweak kemasan 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 memiliki seperangkat pedoman untuk mengatur versi / nomor rilis paket pra-rilis . Pada dasarnya Anda menggunakan nomor versi dari apa yang akan menjadi rilis terakhir Version, dan mulai Releasenomor dengan 0., angka yang bertambah, dan kemudian alpha, betaatau apa pun. Anda tidak akan menggunakan tag alfanumerik finaluntuk rilis final sama sekali.

Perhatikan bahwa Anda tidak dapat mengandalkan RPM yang memiliki dukungan untuk versi tilde gaya Debian. Beberapa distribusi menonaktifkan fitur ini.

Saya bukan penggemar perbedaan alpha / beta. Ada kode yang dirilis dan kode yang belum dirilis.

Bagaimana saya melakukannya: Saya suka major.minor.build dengan sistem integrasi berkelanjutan (lihat JenkinsCI). Build integer tidak pernah diatur ulang. Perubahan nomor versi kecil adalah untuk perubahan yang kompatibel ke belakang. Perubahan angka besar adalah penawaran besar.

Jika pemasaran tidak suka "build" menjadi bilangan bulat besar, Anda bisa menambah angka minor satu kali untuk pemasaran hanya pada build yang dirilis, dan kemudian lagi ketika masuk ke engineering.

Saya bertemu dengan masalah yang sama dan saya harus membandingkan revisi antara paket RedHat, Debian, Python, dan permata Ruby untuk menyatukan nomor suite, dan ini membantu saya untuk mengevaluasi "lebih dari" dan "kurang dari" dalam setiap kasus:

Ini membandingkan 1.3.0.post0.dev20180213210433 ke 1.3.0, YMMV

untuk Red Hat (terima kasih ke 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

Untuk 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

Untuk 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

Untuk 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

Pada versi 4.10.0, RPM secara resmi mendukung penomoran tilde gaya dpkg yang disebutkan dalam pertanyaan.

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