«Номера» версии инкрементного пакета RPM для xyz> xyz-beta (или alpha, rc и т. Д.)

Чтобы публиковать пакеты 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 ».

Альтернативой, которую я рассмотрел, является использование раздела «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 / etc отказывается обновляться до 2.4.0, поэтому моя проблема.

Какие номера версий можно использовать для достижения этой цели, и убедитесь, что RPM всегда считает номера версий в порядке. Или, если не номера версий, другой механизм в упаковке RPM?

Примечание 1: Я хотел бы оставить поле «Release:» в файле спецификации для его первоначального назначения (несколько выпусков пакетов, включая изменения пакетов, для одной и той же версии упакованного программного обеспечения).

Примечание 2: Это должно работать на текущих производственных версиях основных дистрибутивов, таких как RHEL / CentOS 6 и SLES 11. Но я заинтересован в решениях, которые тоже этого не делают, если только они не требуют перекомпиляции rpm!

Примечание 3: В Debian-подобных системах dpkg использует специальный номер в номере версии, который является символом «~» (тильда). Это заставляет dpkg считать суффикс как «отрицательный» порядок, так что «2.4.0 ~ что угодно» будет предшествовать «2.4.0». Затем нормальное упорядочение применяется после «~», поэтому «2.4.0 ~ alpha1» предшествует «2.4.0 ~ beta1», потому что «alpha» предшествует «beta» в алфавитном порядке. Я не обязательно хочу использовать ту же схему для пакетов RPM (я почти уверен, что такого эквивалента не существует), так что это просто FYI.

В официальных руководствах по rpm рассказывается, как это сделать, и ссылки на страницу с примерами . Вот пример того, как вы будете работать с очень распространенной схемой управления версиями, которая использует три уровня предварительной версии (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/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

Для питона

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