Xyz> xyz-beta (veya alfa, rc, vb.) İçin artımlı RPM paket sürümü “sayılar”

Bazı yazılımların birkaç farklı sürümünün RPM paketlerini yayınlamak için, "yükseltme" olarak kabul edilen "sayılar" sürümünü belirtmenin ve (sırayla (sırayla) ): "2.4.0 alfa 1", "2.4.0 alfa 2", "2.4.0 alfa 3", "2.4.0 beta 1", "2.4.0 beta 2", "2.4.0 sürüm adayı", "2.4.0 final", "2.4.1", "2.4.2" vb.

Bununla ilgili ana sorun, RPM'nin "2.4.0" ın "2.4.0.alpha1" den daha önce geldiğini düşünmesi, bu yüzden son sürüm numarasının sonuna sonek ekleyemem.

"2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final" i deneyebilirim, ancak "2.4.0.final'den daha sonra kabul edilecek" serbest bırakma adayı "dışında ".

Düşündüğüm bir alternatif RPM sürüm numarasının "epoch:" bölümünü kullanmaktır (epoch: öneki ana sürüm numarasından önce dikkate alınır, böylece "1: 2.4.0" aslında "2: 1.0.0" dan daha erken olur) . Epoch: alanına bir zaman damgası koyarak, tüm sürümler RPM tarafından beklendiği gibi sıralanır, çünkü sürümleri zamanla artmaktadır. Ancak, aynı anda birkaç ana sürümde yeni sürümler yapıldığında bu başarısız olur (örneğin, 2.3.2 2.4.0'dan sonra yayınlanır, ancak RPM sürümleri "20121003: 2.3.2" ve "20120928: 2.4'tür. 0 "ve 2.3.2 üzerindeki sistemler 2.4.0'a" yükseltilemez ", çünkü rpm daha eski bir sürüm olarak görür). Bu durumda, yum / zypper / vb 2.4.0'a yükseltmeyi reddeder, bu yüzden benim sorunum.

Bunu yapmak için hangi sürüm numaralarını kullanabilirim ve RPM'nin her zaman sürüm numaralarının sırayla olduğunu düşündüğünden emin olabilirim. Veya sürüm numaraları değilse, RPM ambalajındaki diğer mekanizmalar?

Not 1: Spesifikasyon dosyasının "Release:" alanını orijinal amacı için saklamak istiyorum (ambalajlı yazılımın aynı sürümü için ambalaj değişiklikleri de dahil olmak üzere çeşitli ambalaj sürümleri).

Not 2: Bu, RHEL / CentOS 6 ve SLES 11 gibi büyük dağıtımların mevcut üretim sürümleri üzerinde çalışmalıdır. Ancak, rpm'yi yeniden derlemesini içermediği sürece ben de olmayan çözümlerle ilgileniyorum!

Not 3: Debian benzeri sistemlerde, dpkg sürüm numarasında "~" (tilde) karakteri olan özel bir bileşen kullanır. Bu, dpkg son ekini "negatif" sıralama olarak saymaya neden olur, böylece "2.4.0 ~ herhangi bir şey" "2.4.0" dan önce gelir. Daha sonra, "~" dan sonra normal sıralama uygulanır, bu nedenle "2.4.0 ~ alfa1" "2.4.0 ~ beta1" den önce gelir, çünkü "alfa" alfabetik olarak "beta" dan önce gelir. Ben mutlaka RPM paketleri için aynı düzeni kullanmak istemiyorum (bu tür eşdeğer var eminim), bu yüzden bu sadece FYI.

Resmi devir kurallar bunun nasıl anlatmak ve bağlantılar bir örnek sayfa . Aşağıda, üç ön sürüm (a, b, rc) kullanan çok yaygın sürüm oluşturma şemasıyla nasıl çalışacağınıza dair bir örnek verilmiştir (bu, rpm'nin maalesef biraz karmaşık olmasını sağlar):

• 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, ikinci sürüm (1.0.0b2'nin paketleme ayarı) -> 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'nın yayın öncesi paketlerin sürüm / sürüm sayısını ayarlamak için bir dizi kılavuzu vardır . Temel olarak son sürüm ne olacağını sürüm numarasını kullanmak Versionve başlangıç Releaseile numarayı 0., artan bir sayı ve ardından alpha, betaya da her neyse. finalSon sürüm için hiçbir alfasayısal etiket kullanmazsınız .

Debian tarzı tilde sürüm desteği olan RPM'ye güvenemeyeceğinizi unutmayın. Birkaç dağıtım bu özelliği devre dışı bırakır.

Alfa / beta ayrımlarının hayranı değilim. Serbest bırakılmış kod ve yayınlanmamış kod var.

Nasıl yaparım: Ben sürekli bir entegrasyon sistemi ile major.minor.build seviyorum (bakınız JenkinsCI). Derleme tamsayı asla sıfırlanmaz. Küçük sürüm numarası değişiklikleri geriye dönük olarak uyumlu değişiklikler içindir. Büyük sayı değişiklikleri büyük fırsatlar.

Pazarlama "derlemenin" büyük tamsayı olmasını sevmezse, yalnızca serbest bırakılan derlemelerde pazarlama için küçük sayıyı bir kez artırabilir ve daha sonra mühendisliğe gittiğinde tekrar artırabilirsiniz.

Benzer bir sorunla karşılaştım ve süit numarasını birleştirmek için RedHat, Debian, Python paketleri ve Ruby mücevherleri arasındaki revizyonları karşılaştırmak zorunda kaldım ve bu her durumda "büyüktür" ve "küçüktür" değerlerini değerlendirmeme yardımcı oldu:

Bu karşılaştırma 1.3.0.post0.dev20180213210433 ile 1.3.0, YMMV

Red Hat için ( https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparison sayesinde )

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 için:

$ 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 için

>>> 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 için

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 sürümünden itibaren RPM, soruda belirtilen dpkg tarzı tilde numaralandırmasını resmi olarak desteklemektedir.

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