22.4.3 Numéros de version

Nous n’incluons en général que la dernière version d’un projet de logiciel libre donné. Mais parfois, par exemple pour des versions incompatibles de bibliothèques, deux (ou plus) versions du même paquet sont requises. Elles ont besoin d’un nom de variable Scheme différent. Nous utilisons le nom défini dans Conventions de nommage pour la version la plus récente ; les versions précédentes utilisent le même nom, suffixé par - et le plus petit préfixe du numéro de version qui permet de distinguer deux versions.

Le nom dans la définition du paquet est le même pour toutes les versions d’un paquet et ne contient pas de numéro de version.

Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de cette manière :

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

Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière

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

Parfois, nous incluons des paquets provenant d’instantanés de systèmes de contrôle de version (VCS) au lieu de versions publiées formellement. Cela devrait rester exceptionnel, car c’est le rôle des développeurs amont de spécifier quel est la version stable. Cependant, c’est parfois nécessaire. Donc, que faut-il mettre dans le champ version ?

Clairement, nous devons rendre l’identifiant de commit de l’instantané du VCS visible dans la version, mais nous devons aussi nous assurer que la version augmente de manière monotone pour que guix package --upgrade puisse déterminer quelle version est la plus récente. Comme les identifiants de commits, notamment avec Git, n’augmentent pas, nous ajoutons un numéro de révision qui nous augmentons à chaque fois que nous mettons à jour vers un nouvel instantané. La chaîne qui en résulte ressemble à cela :

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID du commit en amont
  |    |
  |    `--- révision du paquet Guix
  |
dernière version en amont

C’est une bonne idée de tronquer les identifiants dans le champ version à disons 7 caractères. Cela évite un problème esthétique (en supposant que l’esthétique ait un rôle à jouer ici) et des problèmes avec les limites de l’OS comme la longueur maximale d’un shebang (127 octets pour le noyau Linux). Il y a des fonctions auxiliaires pour faire cela avec les paquets qui utilisent git-fetch ou hg-fetch (voir plus bas). Il vaut mieux cependant utiliser l’identifiant de commit complet dans origin, pour éviter les ambiguïtés. Une définition de paquet peut ressembler à ceci :

(define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;révision du paquet Guix
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn…"))
                (file-name (git-file-name name version))))
      ;; …
      )))

Procédure Scheme : git-version VERSION REVISION COMMIT

Renvoie la chaîne de version pour les paquets qui utilisent git-fetch.

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

Procédure Scheme : hg-version VERSION REVISION CHANGESET

Renvoie la chaîne de version pour les paquets qui utilisent hg-fetch. Cela fonctionne de la même manière que git-fetch.