22.4.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 pacote guix --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

It is a good idea to strip commit identifiers in the version field to, say, 7 digits. It avoids an aesthetic annoyance (assuming aesthetics have a role to play here) as well as problems related to OS limits such as the maximum shebang length (127 bytes for the Linux kernel). There are helper functions for doing this for packages using git-fetch or hg-fetch (see below). It is best to use the full commit identifiers in origins, though, to avoid ambiguities. A typical package definition may look like this:

(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))))
      ;; …
      )))

Scheme Procedure: git-version VERSION REVISION COMMIT

Return the version string for packages using git-fetch.

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

Scheme Procedure: hg-version VERSION REVISION CHANGESET

Return the version string for packages using hg-fetch. It works in the same way as git-version.