Versão incremental do pacote RPM "números" para xyz> xyz-beta (ou alfa, rc, etc)

Para publicar pacotes RPM de várias versões diferentes de alguns softwares, estou procurando uma maneira de especificar "números" de versões considerados "atualizações" e incluir a diferenciação de várias versões de pré-lançamento, como (em ordem ): "2.4.0 alfa 1", "2.4.0 alfa 2", "2.4.0 alfa 3", "2.4.0 beta 1", "2.4.0 beta 2", "candidato à versão 2.4.0", "2.4.0 final", "2.4.1", "2.4.2" etc.

O principal problema que tenho com isso é que o RPM considera que "2.4.0" vem antes de "2.4.0.alpha1", então não posso simplesmente adicionar o sufixo no final do número da versão final.

Eu poderia tentar "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", que funcionaria, exceto o "candidato à liberação" que seria considerado posterior a "2.4.0.final "

Uma alternativa que considerei é usar a seção "epoch:" do número da versão do RPM (o prefixo epoch: é considerado antes do número da versão principal, para que "1: 2.4.0" seja realmente anterior a "2: 1.0.0") . Ao colocar um registro de data e hora no campo epoch:, todas as versões são ordenadas conforme o esperado pelo RPM, porque suas versões parecem aumentar com o tempo. No entanto, isso falha quando novas versões são feitas em várias versões principais ao mesmo tempo (por exemplo, o 2.3.2 é lançado após a 2.4.0, mas sua versão para o RPM é "20121003: 2.3.2" e "20120928: 2.4. 0 "e os sistemas no 2.3.2 não podem ser" atualizados "para o 2.4.0, porque o rpm o vê como uma versão mais antiga). Nesse caso, o yum / zypper / etc se recusa a atualizar para a 2.4.0, daí o meu problema.

Quais números de versão posso usar para fazer isso e verifique se o RPM sempre considera os números de versão em ordem. Ou, se não for o número da versão, outro mecanismo no pacote RPM?

Nota 1: Gostaria de manter o campo "Release:" do arquivo de especificações para sua finalidade original (várias versões de pacotes, incluindo alterações de pacotes, para a mesma versão do software empacotado).

Nota 2: Isso deve funcionar nas versões atuais de produção de grandes distribuições, como RHEL / CentOS 6 e SLES 11. Mas estou interessado em soluções que também não o fazem, desde que não envolvam a recompilação de rpm!

Nota 3: Em sistemas do tipo Debian, o dpkg usa um componente especial no número da versão, que é o caractere "~" (til). Isso faz com que o dpkg conte o sufixo como ordem "negativa", de modo que "2.4.0 ~ qualquer coisa" venha antes de "2.4.0". Em seguida, a ordem normal se aplica após o "~", então "2.4.0 ~ alpha1" vem antes de "2.4.0 ~ beta1" porque "alpha" vem antes de "beta" em ordem alfabética. Eu não estou necessariamente procurando usar o mesmo esquema para pacotes RPM (tenho certeza de que não existe esse equivalente), então isso é apenas para sua informação.

As diretrizes oficiais de rpm informam como fazer isso e links para uma página de exemplos . Aqui está um exemplo de como você trabalharia com o esquema de versão muito comum que usa três níveis de pré-lançamento (a, b, rc) (que rpm infelizmente dificulta um pouco o suporte):

• 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 versão (ajuste de pacote 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

O Fedora possui um conjunto de diretrizes para definir o número da versão / release dos pacotes de pré-lançamento . Basicamente, você usa o número da versão do que será o release final Versione inicia o Releasenúmero com 0.um número incremental e alpha, em seguida , betaou o que for. Você não usaria uma tag alfanumérica finalpara a versão final.

Note que você não pode contar com o RPM tendo suporte para o versionamento de til no estilo Debian. Várias distribuições desabilitam esse recurso.

Não sou fã de distinções alfa / beta. Há código liberado e código não liberado.

Como faço: Gosto do major.minor.build com um sistema de integração contínua (consulte JenkinsCI). O número inteiro da compilação nunca é redefinido. Pequenas alterações no número da versão são para alterações compatíveis com versões anteriores. Grandes mudanças de número são grandes negócios.

Se o marketing não gostar da "compilação" como números inteiros grandes, você poderá incrementar o número menor uma vez para o marketing apenas nas compilações liberadas e depois novamente quando for para a engenharia.

Eu me deparei com um problema semelhante e tive que comparar revisões entre pacotes RedHat, Debian, Python e gemas Ruby para unificar o número do conjunto, e isso me ajudou a avaliar o "maior que" e "menor que" em cada caso:

Isso está comparando 1.3.0.post0.dev20180213210433 com 1.3.0, YMMV

para Red Hat (graças 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 o 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 da versão 4.10.0, o RPM suporta oficialmente a numeração de til no estilo dpkg mencionada na pergunta.

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