Next: , Previous: , Up: 打包指导   [Contents][Index]


16.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")
    ...))

有时候,我们为软件包上游的版本控制系统(VCS)的快照而不是正式发布版打包。这是特殊情况,因为决定哪个是稳定版的权力应该属于上游开发者。然而,有时候这是必须的。那么,我们该如何决定写在version里的版本号呢?

显然,我们需要让VCS快照的commit ID在版本号中体现出来,但是我们也需要确保版本号单调递增,以便guix package --upgrade决定哪个版本号更新。由于commit ID,尤其是Git的commit ID,不是单调递增的,我们添加一个每次升级快照时都手动增长的revision数字。最后的版本号字符串看起来是这样:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- 上游的commit ID
  |    |
  |    `--- Guix软件包的revision
  |
最新的上游版本号

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). 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软件包的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))))
      ;; …
      )))