22.8.3 Números de versão

Geralmente, empacotamos apenas a versão mais recente de um determinado projeto de software livre. Mas, às vezes, por exemplo, para versões incompatíveis de bibliotecas, são necessárias duas (ou mais) versões do mesmo pacote. Isso requer nomes de variáveis Scheme diferentes. Usamos o nome como definido em Nomeando um pacote para a versão mais recente; as versões anteriores usam o mesmo nome, com o sufixo - e o menor prefixo do número da versão que pode distinguir as duas versões.

O nome dentro da definição do pacote é o mesmo para todas as versões de um pacote e não contém nenhum número de versão.

Por exemplo, as versões 2.24.20 e 3.9.12 do GTK podem ser empacotados da seguinte forma:

(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))

Se também quiséssemos GTK 3.8.2, este seria empacotado como

(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))

Ocasionalmente, empacotamos snapshots do sistema de controle de versão (VCS) do upstream em vez de lançamentos formais. Isso deve permanecer excepcional, porque cabe aos desenvolvedores upstream esclarecer qual é a versão estável. No entanto, às vezes é necessário. Então, o que devemos colocar no campo version?

Claramente, precisamos tornar o identificador de commit do snapshot VCS visível na string de versão, mas também precisamos garantir que a string de versão esteja aumentando monotonicamente para que o guix package --upgrade possa determinar qual versão é mais recente. Como os identificadores de commit, principalmente com o Git, não estão aumentando monotonicamente, adicionamos um número de revisão que aumentamos cada vez que atualizamos para um snapshot mais recente. A sequência da versão resultante é assim:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID do commit do upstream
  |    |
  |    `--- revisão do pacote do Guix
  |
versão mais recente do upstream

É uma boa ideia reduzir os identificadores de commit no campo version para, digamos, 7 dígitos. Isso evita um incômodo estético (assumindo que a estética tenha um papel a desempenhar aqui), bem como problemas relacionados aos limites do sistema operacional, como o comprimento máximo do shebang (127 bytes para o kernel Linux). Existem funções auxiliares para fazer isso para pacotes usando git-fetch ou hg-fetch (veja abaixo). Porém, é melhor usar os identificadores de commit completos em origins para evitar ambiguidades. Uma definição típica de pacote pode ser assim:

(define meu-pacote
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;revisão do pacote do Guix
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/meu-pacote.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn…"))
                (file-name (git-file-name name version))))
      ;; …
      )))

Procedimento: git-version VERSION REVISION COMMIT

Retorne a string de versão para pacotes usando git-fetch.

(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
⇒ "0.2.3-0.93818c9"

Procedimento: hg-version VERSION REVISION CHANGESET

Retorne a string de versão para pacotes usando hg-fetch. Funciona da mesma forma que git-version.