Versão do pacote RPM incremental “números” para x.y.z x.y.z-beta (ou alpha, rc, etc)

Question

Para publicar pacotes RPM de várias versões diferentes de algum software, estou procurando uma maneira de especificar "números" de versão que são 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", "versão 2.4.0 candidato "," 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. / p>

Eu poderia tentar "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final", o que funcionaria, exceto pelo "release candidate" 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 na verdade anterior a "2: 1.0". 0 "). Colocando um timestamp no campo epoch:, todas as versões são ordenadas conforme o esperado pelo RPM, porque suas versões parecem aumentar no tempo. No entanto, isso falha quando novas versões são feitas em várias versões principais ao mesmo tempo (por exemplo, 2.3.2 é lançado após 2.4.0, mas sua versão para RPM é "20121003: 2.3.2" e "20120928: 2.4". 0 "e sistemas em 2.3.2 não podem obter" upgrade "para 2.4.0, porque o rpm o vê como uma versão mais antiga). Neste caso, yum / zypper / etc se recusam a atualizar para o 2.4.0, portanto, meu problema.

Quais números de versão eu posso usar para conseguir isso e garantir que o RPM sempre considere os números de versão em ordem. Ou, se não os números de versão, outro mecanismo no empacotamento RPM?

Nota 1: Eu gostaria de manter o campo "Release:" do arquivo de especificações para seu propósito original (várias versões de pacotes, incluindo mudanças de pacotes, para a mesma versão do software empacotado).

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

Nota 3: Em sistemas do tipo Debian, o dpkg usa um componente especial no número da versão que é o caractere "~" (til). Isto faz com que o dpkg conte o sufixo como ordem "negativa", de forma que "2.4.0 ~ qualquer coisa" venha antes de "2.4.0". Então, a ordenação 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" alfabeticamente. Eu não estou necessariamente olhando para usar o mesmo esquema para pacotes RPM (eu tenho certeza que não existe tal equivalente), então isso é apenas FYI.

    

Answer 1

As diretrizes oficiais do rpm dizem como fazer isso, e links para uma página de exemplos . Aqui está um exemplo de como você trabalharia com o esquema de versionamento muito comum que usa três níveis de pré-lançamento (a, b, rc) (o que o rpm infelizmente dificulta 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 embalagem 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

Answer 2

O Fedora tem um conjunto de diretrizes para definir a versão / versão do pacote de pré-lançamento . Basicamente, você usa o número da versão do que será a versão final em Version e inicia o número Release com 0. , um número incremental e, em seguida, alpha , beta ou o que for. Você não usaria uma tag alfanumérica final para a versão final.

Note que você não pode contar com o RPM tendo suporte para o versionamento de til do estilo Debian. Diversas distribuições desativam esse recurso.

    

Answer 3

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

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

Se o marketing não gostar do "build" para ser inteiros grandes, você pode incrementar o número menor uma vez para marketing apenas em compilações lançadas e, novamente, quando for para engenharia.