22.4.3 Номера версий

Обычно мы опакечиваем только последнюю версию некоторого программного обеспечения. Но иногда, например, при наличии несовместимых версий библиотек, нужны две (или более) версии одного пакета. Это требует разных имён переменных Scheme. Мы используем имя, определённое в Как называть пакеты, для самой последней версии; предыдущие версии используют такое же имя с добавлением - и номера версии, что позволяет отличить две версии.

Имя внутри описания пакета остаётся одно для всех версий пакета и не содержит номера версии.

Например, версии GTK+ 2.24.20 и 3.9.12 могут опакечиваться так:

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

Если нам также нужен GTK+ 3.8.2, он будет размещён в пакете

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

Порой мы опакечиваем снепшоты исходников из системы контроля версий (СКВ) вместо официальных релизов. Это остаётся исключением, потому что только разработчики оригинальных программ решают, что является стабильным релизом. Иногда это имеет значение. Что же мы должны писать в поле версия?

Ясно, что нужно сделать отображение идентификатора коммита снепшота СКВ внутри строки версии, но мы также должны убедиться, что строка "версия" монотонно увеличивается, так чтобы guix package --upgrade могла определить, какая версия новее. Так как идентификаторы коммитов, что точно, Git, не увеличиваются, мы добавляем номер ревизии, которую мы увеличиваем каждый раз, когда мы обновляем до нового снепшота. Результирующая строка версии выглядит так:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID коммита оригинала
  |    |
  |    `--- версия пакета Guix 
  |
последняя версия оригинала

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 my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Guix package revision
    (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))))
      ;; …
      )))

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.