„Numery” wersji przyrostowej pakietu RPM dla xyz> xyz-beta (lub alpha, rc itp.)

Aby opublikować pakiety RPM kilku różnych wersji niektórych programów, szukam sposobu na określenie „numerów” wersji, które są uważane za „aktualizacje”, i uwzględnienie różnicowania kilku wersji przedpremierowych, takich jak (w kolejności ): „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”, „kandydat do wydania 2.4.0”, „2.4.0 wersja ostateczna”, „2.4.1”, „2.4.2” itd.

Głównym problemem, jaki mam z tym, jest to, że RPM uważa, że ​​„2.4.0” jest wcześniejszy niż „2.4.0.alpha1”, więc nie mogę po prostu dodać sufiksu na końcu ostatecznego numeru wersji.

Mógłbym wypróbować „2.4.0.alpha1”, „2.4.0.beta1”, „2.4.0.final”, które działałyby, z wyjątkiem „kandydata do wydania”, który byłby rozważany później niż „2.4.0.final „.

Alternatywą, którą rozważałem, jest użycie sekcji „epoka:” numeru wersji RPM (przedrostek epoki: rozważany jest przed głównym numerem wersji, tak że „1: 2.4.0” jest faktycznie wcześniejszy niż „2: 1.0.0”) . Umieszczając znacznik czasu w polu epoka:, wszystkie wersje są porządkowane zgodnie z oczekiwaniami RPM, ponieważ ich wersje wydają się rosnąć w czasie. Nie powiedzie się to jednak, gdy zostaną wydane nowe wersje dla kilku głównych wersji jednocześnie (na przykład 2.3.2 jest wydana po wersji 2.4.0, ale ich wersja dla RPM to „20121003: 2.3.2” i „20120928: 2.4. 0 ”i systemy w wersji 2.3.2 nie mogą zostać„ zaktualizowane ”do wersji 2.4.0, ponieważ rpm widzi to jako starszą wersję). W tym przypadku yum / zypper / etc odmawia aktualizacji do wersji 2.4.0, więc mój problem.

Jakich numerów wersji mogę użyć, aby to osiągnąć, i upewnij się, że RPM zawsze uważa, że ​​numery wersji są w porządku. A jeśli nie numery wersji, inny mechanizm w pakiecie RPM?

Uwaga 1: Chciałbym zachować pole „Wydanie:” pliku specyfikacji do jego pierwotnego celu (kilka wydań pakietów, w tym zmiany w pakiecie, dla tej samej wersji pakietu).

Uwaga 2: Powinno to działać w bieżących wersjach głównych dystrybucji, takich jak RHEL / CentOS 6 i SLES 11. Ale interesują mnie rozwiązania, które również nie, o ile nie wymagają ponownej kompilacji rpm!

Uwaga 3: W systemach podobnych do Debiana dpkg używa specjalnego komponentu w numerze wersji, który jest znakiem „~” (tylda). Powoduje to, że dpkg liczy przyrostek jako „ujemny” porządek, tak że „2.4.0 ~ cokolwiek” pojawi się przed „2.4.0”. Następnie po „~” obowiązuje normalne uporządkowanie, więc „2.4.0 ~ alpha1” występuje przed „2.4.0 ~ beta1”, ponieważ „alfa” występuje przed „beta” alfabetycznie. Niekoniecznie chcę używać tego samego schematu dla pakietów RPM (jestem prawie pewien, że nie ma takiego odpowiednika), więc to tylko informacja FYI.

Te oficjalne wytyczne rpm powiedzieć, jak to zrobić, a linki do na stronie przykłady . Oto przykład, w jaki sposób pracowałbyś z bardzo popularnym schematem kontroli wersji, który wykorzystuje trzy poziomy wersji wstępnej (a, b, rc) (której rpm niestety komplikuje nieco obsługę):

• 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, drugie wydanie (ulepszenie opakowania 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 ma zestaw wskazówek dotyczących ustawiania numeru wersji / wydania pakietów przedpremierowych . Zasadniczo używasz numeru wersji, która będzie ostateczną wersją Version, i zaczynasz od Releasenumeru 0.rosnącego, a następnie alpha, betalub cokolwiek innego. W finalostatecznym wydaniu w ogóle nie używałbyś alfanumerycznego znacznika .

Zauważ, że nie możesz liczyć na to, że RPM będzie obsługiwał wersje tyldowe w stylu Debiana. Kilka dystrybucji wyłącza tę funkcję.

Nie jestem fanem wyróżnień alfa / beta. Jest kod zwolniony i kod niepublikowany.

Jak to robię: podoba mi się major.minor.build z systemem ciągłej integracji (patrz JenkinsCI). Kompilacja liczb całkowitych nigdy nie jest resetowana. Niewielkie zmiany numerów wersji dotyczą zmian kompatybilnych wstecz. Najważniejsze zmiany liczbowe to wielkie okazje.

Jeśli marketing nie lubi, aby „kompilacja” była dużymi liczbami całkowitymi, możesz zwiększyć liczbę mniejszą jeden raz w celu marketingu tylko w wydanych kompilacjach, a potem jeszcze raz, jeśli chodzi o inżynierię.

Wpadłem na podobny problem i musiałem porównać wersje między pakietami RedHat, Debian, Python i klejnotami Ruby, aby ujednolicić numer pakietu, co pomogło mi ocenić w każdym przypadku „większe niż” i „mniejsze niż”:

Porównuje to 1.3.0.post0.dev20180213210433 z 1.3.0, YMMV

dla Red Hat (dzięki 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

W przypadku Debiana:

$ 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

Dla Pythona

>>> 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

Dla 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

Począwszy od wersji 4.10.0, RPM oficjalnie obsługuje numerację tyldy w stylu dpkg wspomnianą w pytaniu.

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