"Numeri" di pacchetti RPM incrementali per xyz> xyz-beta (o alpha, rc, ecc.)

Per pubblicare pacchetti RPM di diverse versioni di alcuni software, sto cercando un modo per specificare i "numeri" di versione che sono considerati "aggiornamenti" e includano la differenziazione di diverse versioni pre-release, come (in ordine ): "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 candidate candidate", "2.4.0 final", "2.4.1", "2.4.2", ecc.

Il problema principale che ho con questo è che RPM considera che "2.4.0" arriva prima di "2.4.0.alpha1", quindi non posso semplicemente aggiungere il suffisso alla fine del numero di versione finale.

Potrei provare "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", che funzionerebbe, ad eccezione del "candidato candidato" che verrà considerato dopo "2.4.0.final ".

Un'alternativa che ho preso in considerazione è l'uso della sezione "epoca:" del numero di versione di RPM (l'epoca: il prefisso è considerato prima del numero di versione principale in modo che "1: 2.4.0" sia effettivamente precedente a "2: 1.0.0") . Inserendo un timestamp nel campo epoch:, tutte le versioni vengono ordinate come previsto da RPM, poiché le loro versioni sembrano aumentare nel tempo. Tuttavia, ciò non riesce quando vengono rilasciate nuove versioni contemporaneamente su più versioni principali (ad esempio, 2.3.2 viene rilasciato dopo la 2.4.0, ma le loro versioni per RPM sono "20121003: 2.3.2" e "20120928: 2.4. 0 "e i sistemi su 2.3.2 non possono essere" aggiornati "a 2.4.0, perché rpm lo vede come una versione precedente). In questo caso, yum / zypper / etc si rifiutano di passare alla 2.4.0, quindi il mio problema.

Quali numeri di versione posso usare per raggiungere questo obiettivo e assicurati che RPM consideri sempre i numeri di versione in ordine. O se non i numeri di versione, altri meccanismi nella confezione RPM?

Nota 1: Vorrei mantenere il campo "Rilascio:" del file delle specifiche per lo scopo originale (diverse versioni di pacchetti, comprese le modifiche al pacchetto, per la stessa versione del software in pacchetto).

Nota 2: Questo dovrebbe funzionare con le attuali versioni di produzione delle principali distribuzioni, come RHEL / CentOS 6 e SLES 11. Ma sono interessato a soluzioni che non lo fanno, purché non comportino la ricompilazione di rpm!

Nota 3: Su sistemi simili a Debian, dpkg usa un componente speciale nel numero di versione che è il carattere "~" (tilde). Questo fa sì che dpkg conteggi il suffisso come ordine "negativo", in modo che "2.4.0 ~ nulla" venga prima di "2.4.0". Quindi, l'ordinamento normale si applica dopo "~", quindi "2.4.0 ~ alpha1" precede "2.4.0 ~ beta1" perché "alpha" precede "beta" in ordine alfabetico. Non sto necessariamente cercando di usare lo stesso schema per i pacchetti RPM (sono abbastanza sicuro che non esiste tale equivalente), quindi questo è solo FYI.

Le linee guida rpm ufficiali spiegano come eseguire questa operazione e collegano a una pagina di esempi . Ecco un esempio di come lavoreresti con lo schema di versioning molto comune che utilizza tre livelli di pre-release (a, b, rc) (che rpm purtroppo rende leggermente complicato il supporto):

• 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, seconda versione (ottimizzazione della confezione di 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 ha una serie di linee guida per impostare il numero di versione / versione dei pacchetti pre-release . Fondamentalmente usi il numero di versione di quella che sarà la versione finale in Version, e inizi il Releasenumero con 0.un numero crescente, e poi alpha, betao qualsiasi altra cosa. Non utilizzare affatto un tag alfanumerico finalper la versione finale.

Nota che non puoi contare su RPM con supporto per il controllo delle versioni tilde in stile Debian. Diverse distribuzioni disabilitano questa funzione.

Non sono un fan delle distinzioni alfa / beta. C'è un codice rilasciato e un codice inedito.

Come lo faccio: mi piace major.minor.build con un sistema di integrazione continua (vedi JenkinsCI). Il numero intero di build non viene mai ripristinato. Le modifiche minori al numero di versione sono per modifiche compatibili con le versioni precedenti. Le principali variazioni di numero sono grandi affari.

Se al marketing non piace che la "build" sia un numero intero di grandi dimensioni, è possibile incrementare il numero minore una volta per il marketing solo sui build rilasciati e poi di nuovo quando si passa all'ingegneria.

Ho riscontrato un problema simile e ho dovuto confrontare le revisioni tra i pacchetti RedHat, Debian, Python e le gemme Ruby per unificare il numero della suite, e questo mi ha aiutato a valutare "maggiore di" e "minore di" in ogni caso:

Questo sta confrontando 1.3.0.post0.dev20180213210433 con 1.3.0, YMMV

per Red Hat (grazie 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

Per 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

Per 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

Per 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 partire dalla versione 4.10.0, RPM supporta ufficialmente la numerazione delle tilde in stile dpkg menzionata nella domanda.

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