22.4.3 Versiones numéricas

Normalmente empaquetamos únicamente la última versión de un proyecto dado de software libre. Pero a veces, por ejemplo para versiones de bibliotecas incompatibles, se necesitan dos (o más) versiones del mismo paquete. Estas necesitan nombres diferentes para las variables Scheme. Usamos el nombre como se define en Nombrado de paquetes para la versión más reciente; las versiones previas usan el mismo nombre, añadiendo un - y el prefijo menor del número de versión que permite distinguir las dos versiones.

El nombre dentro de la definición de paquete es el mismo para todas las versiones de un paquete y no contiene ningún número de versión.

Por ejemplo, las versiones 2.24.20 y 3.9.12 de GTK+ pueden empaquetarse como sigue:

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

Si también deseásemos GTK+3.8.2, se empaquetaría como

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

De manera ocasional, empaquetamos instantáneas del sistema de control de versiones (VCS) de las desarrolladoras originales en vez de publicaciones formales. Esto debería permanecer como algo excepcional, ya que son las desarrolladoras originales quienes deben clarificar cual es la entrega estable. No obstante, a veces es necesario. Por tanto, ¿qué deberíamos poner en el campo version?

Claramente, tenemos que hacer visible el identificador de la revisión en el VCS en la cadena de versión, pero también debemos asegurarnos que la cadena de versión incrementa monotónicamente de manera que guix package --upgrade pueda determinar qué versión es más moderna. Ya que los identificadores de revisión, notablemente en Git, no incrementan monotónicamente, añadimos un número de revisión que se incrementa cada vez que actualizamos a una nueva instantánea. La versión que resulta debería ser así:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID de revisión original
  |    |
  |    `--- revisión del paquete Guix
  |
última versión de publicación

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 mi-paquete
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Revisión Guix del paquete
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/mi-paquete.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

Devuelve la cadena de versión de los paquetes utilizando hg-fetch. Funciona de la misma manera que git-version.