Версія пакета RPM "цифри" для xyz> xyz-beta (або альфа, rc тощо)

Для того, щоб публікувати пакети RPM декількох різних версій певного програмного забезпечення, я шукаю спосіб вказати "номери" версій, які вважаються "оновленнями", і включати диференціацію кількох попередніх версій, таких як (для того, щоб ): "2.4.0 альфа 1", "2.4.0 альфа 2", "2.4.0 альфа 3", "2.4.0 бета-версія 1", "2.4.0 бета-версія 2", "кандидат на випуск 2.4.0", "2.4.0 остаточний", "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 ".

Я вважав альтернативою використання розділу "epoch:" номера версії 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 не можуть бути" оновлені "до 2.4.0, оскільки rpm сприймає це як старішу версію). У цьому випадку yum / zypper / тощо відмовляються від оновлення до 2.4.0, тому моя проблема.

Які номери версій я можу використовувати, щоб досягти цього, і переконайтесь, що RPM завжди вважає номери версій за порядком. Або якщо не номери версій, інший механізм упаковки RPM?

Примітка 1: Я хотів би зберегти поле "Випуск:" у специфікаційному файлі для його оригінальної мети (декілька випусків пакетів, включаючи зміни упаковки, для тієї ж версії пакуваного програмного забезпечення).

Примітка 2: Це повинно працювати на поточних виробничих версіях основних дистрибутивів, таких як RHEL / CentOS 6 та SLES 11. Але мене цікавлять рішення, які теж не мають, доки вони не передбачають перекомпіляції оборотів у хвилину!

Примітка 3: У системах, схожих на Debian, dpkg використовує спеціальний компонент у номері версії, який є символом "~" (tilde). Це змушує dpkg рахувати суфікс як "негативне" впорядкування, так що "2.4.0 ~ що-небудь" вийде перед "2.4.0". Тоді звичайне впорядкування застосовується після "~", тому "2.4.0 ~ альфа1" надходить до "2.4.0 ~ бета1", оскільки "альфа" надходить "бета" в алфавітному порядку. Мені не обов’язково хочеться використовувати ту саму схему для пакетів RPM (я впевнений, що такого еквівалента не існує), тому це просто FYI.

В офіційних керівних принципів оборотів в хвилину сказати , як це зробити, а також посилання на на сторінці прикладів . Ось приклад того, як ви працювали з дуже поширеною схемою версій, яка використовує три рівні попереднього випуску (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, другий випуск (виправлення упаковки 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). Ціле число збірки ніколи не скидається. Незначні зміни номерів версій призначені для зворотних сумісних змін. Основні зміни кількості - це великі угоди.

Якщо маркетингу не подобається, що «збірка» є великими цілими числами, ви можете збільшити незначне число один раз для маркетингу тільки на версії, що випускаються, і знову, коли йдеться про інжиніринг.

Я зіткнувся з подібною проблемою, і мені довелося порівняти ревізії між пакетами RedHat, Debian, Python та дорогоцінними каменями Ruby, щоб уніфікувати номер набору, і це допомогло мені оцінити "більше ніж" і "менше ніж" у кожному випадку:

Це порівнюючи 1.3.0.post0.dev20180213210433 до 1.3.0, YMMV

для Red Hat (завдяки https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComppare )

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

Для Рубі

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