"Números" de la versión incremental del paquete RPM para xyz> xyz-beta (o alpha, rc, etc.)

Para publicar paquetes RPM de varias versiones diferentes de algún software, estoy buscando una forma de especificar "números" de versión que se consideren "actualizaciones" e incluir la diferenciación de varias versiones preliminares, como (en orden ): "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 versión candidata", "2.4.0 final", "2.4.1", "2.4.2", etc.

El principal problema que tengo con esto es que RPM considera que "2.4.0" viene antes que "2.4.0.alpha1", por lo que no puedo agregar el sufijo al final del número de versión final.

Podría probar "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", que funcionaría, a excepción del "candidato de liberación" que se consideraría más tarde que "2.4.0.final ".

Una alternativa que consideré es usar la sección "epoch:" del número de versión RPM (el prefijo epoch: se considera antes del número de versión principal para que "1: 2.4.0" sea realmente anterior a "2: 1.0.0") . Al poner una marca de tiempo en el campo epoch: todas las versiones se ordenan según lo esperado por RPM, porque sus versiones parecen incrementarse en el tiempo. Sin embargo, esto falla cuando se realizan nuevos lanzamientos en varias versiones principales al mismo tiempo (por ejemplo, 2.3.2 se lanza después de 2.4.0, pero su versión para RPM es "20121003: 2.3.2" y "20120928: 2.4. 0 "y los sistemas en 2.3.2 no pueden" actualizarse "a 2.4.0, porque rpm lo ve como una versión anterior). En este caso, yum / zypper / etc se niegan a actualizar a 2.4.0, por lo tanto, mi problema.

¿Qué números de versión puedo usar para lograr esto y asegurarme de que RPM siempre considere que los números de versión están en orden? ¿O si no los números de versión, otro mecanismo en el paquete RPM?

Nota 1: Me gustaría mantener el campo "Release:" del archivo de especificaciones para su propósito original (varias versiones de paquetes, incluidos cambios de empaque, para la misma versión del software empaquetado).

Nota 2: Esto debería funcionar en las versiones de producción actuales de las principales distribuciones, como RHEL / CentOS 6 y SLES 11. ¡Pero también estoy interesado en soluciones que no lo hagan, siempre que no impliquen recompilar rpm!

Nota 3: en sistemas similares a Debian, dpkg utiliza un componente especial en el número de versión que es el carácter "~" (tilde). Esto hace que dpkg cuente el sufijo como un orden "negativo", de modo que "2.4.0 ~ cualquier cosa" aparecerá antes que "2.4.0". Luego, el orden normal se aplica después de "~", por lo que "2.4.0 ~ alpha1" va antes que "2.4.0 ~ beta1" porque "alpha" viene antes de "beta" alfabéticamente. No estoy buscando necesariamente usar el mismo esquema para paquetes RPM (estoy bastante seguro de que no existe tal equivalente), por lo que esto es solo para su información.

Las pautas oficiales de rpm indican cómo hacer esto y los enlaces a una página de ejemplos . Aquí hay un ejemplo de cómo trabajaría con el esquema de control de versiones muy común que usa tres niveles de prelanzamiento (a, b, rc) (que rpm lamentablemente hace que sea un poco complicado de soportar):

• 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, segunda versión (ajuste de empaque de 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 tiene un conjunto de pautas para configurar la versión / número de lanzamiento de los paquetes de prelanzamiento . Básicamente, usa el número de versión de lo que será la versión final en Version, y comienza el Releasenúmero con 0.un número creciente, y luego alpha, betao lo que sea. No utilizaría una etiqueta alfanumérica finalpara la versión final en absoluto.

Tenga en cuenta que no puede contar con que RPM tenga soporte para las versiones de tilde estilo Debian. Varias distribuciones deshabilitan esta función.

No soy fanático de las distinciones alfa / beta. Hay código publicado y código inédito.

Cómo lo hago: me gusta major.minor.build con un sistema de integración continua (ver JenkinsCI). Build integer nunca se restablece. Los cambios menores en el número de versión son para cambios compatibles con versiones anteriores. Los principales cambios de números son grandes ofertas.

Si al marketing no le gusta que la "compilación" sea un número entero grande, puede incrementar el número menor una vez para comercializar solo en las compilaciones que se lanzan, y luego nuevamente cuando se trata de ingeniería.

Me topé con un problema similar y tuve que comparar las revisiones entre los paquetes RedHat, Debian, Python y las gemas Ruby para unificar el número de la suite, y esto me ayudó a evaluar el "mayor que" y el "menor que" en cada caso:

Esto está comparando 1.3.0.post0.dev20180213210433 con 1.3.0, YMMV

para Red Hat (gracias a 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

Para 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

Para 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

Para 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

A partir de la versión 4.10.0, RPM admite oficialmente la numeración de tilde de estilo dpkg mencionada en la pregunta.

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