[PATCH] doc: Expound on how to specify the version of a package.

Done

Details

4 participants

Ludovic Courtès
Nicolas Goaziou
Maxime Devos
Xinglu Chen

Owner: unassigned

Submitted by: Xinglu Chen

Severity: normal

Xinglu Chen wrote on 26 May 2021 11:00

Recipients:(address . guix-patches@gnu.org)

Message-ID:06217762b07f95d2ba2d40277d010647a926df68.1622019402.git.public@yoctocell.xyz

* doc/guix.texi (package Reference): Describe how packages that lack a release

or are pinned to an unreleased version should specify the ‘version’ field.

Add documentation for the ‘git-version’ procedure.

---

I am unsure if the format for packages that don’t have a release should

be ‘0.0.0-REVISION.COMMIT’ or just ‘0-REVISION.COMMIT’.

doc/guix.texi | 23 ++++++++++++++++++++++-

1 file changed, 22 insertions(+), 1 deletion(-)

Toggle diff (52 lines)diff --git a/doc/guix.texi b/doc/guix.texi
index e8b0485f78..083f65c9c5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -89,6 +89,7 @@ Copyright @copyright{} 2020 Jonathan Brielmaier@*
 Copyright @copyright{} 2020 Edgar Vincent@*
 Copyright @copyright{} 2021 Maxime Devos@*
 Copyright @copyright{} 2021 B. Wilson@*
+Copyright @copyright{} 2021 Xinglu Chen@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -6651,7 +6652,18 @@ This is the data type representing a package recipe.
 The name of the package, as a string.
 
 @item @code{version}
-The version of the package, as a string.
+The version of the package, as a string.  If there are no releases of
+the package, or a unreleased version is desired, the version should
+contain @code{VERSION-REVISION.COMMIT}.  @code{VERSION} is
+@c TODO: 0.0.0 or just 0 ?
+@code{0.0.0} or whatever the latest version is, and @code{REVISION} is
+the revision of the Guix package (@code{0} if it is a new package),
+whenever the package is updated to a newer version the revision should
+also be bumped.  @code{COMMIT} is the @dfn{commit} or @dfn{changeset}
+corresponding to the version, it should only contain 7 characters.  If
+the fetch method is @code{git-fetch} (@pxref{origin Reference}), there
+is the @code{git-version} procedure that makes it easier to specify the
+version.
 
 @item @code{source}
 An object telling how the source code for the package should be
@@ -6757,6 +6769,15 @@ automatically corrected.
 @end table
 @end deftp
 
+@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
+Return the version string for packages using @code{git-fetch}.
+
+@example
+(git-version "0.0.0" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
+@result{} "0.0.0-0.93818c9"
+@end example
+@end deffn
+
 @deffn {Scheme Syntax} this-package
 When used in the @emph{lexical scope} of a package field definition, this
 identifier resolves to the package being defined.

base-commit: 3f2a4b098039bd374c76d524223de3c6c475f23e
-- 
2.31.1

Nicolas Goaziou wrote on 26 May 2021 15:06

Recipients:(name . Xinglu Chen)(address . public@yoctocell.xyz)(address . 48667@debbugs.gnu.org)

Message-ID:87tumphcey.fsf@nicolasgoaziou.fr

Hello,

Xinglu Chen <public@yoctocell.xyz> writes:

Toggle quote (4 lines)

> * doc/guix.texi (package Reference): Describe how packages that lack a release

> or are pinned to an unreleased version should specify the ‘version’ field.

> Add documentation for the ‘git-version’ procedure.

Thanks.

I don't know if all should be included in the manual (though I think

the `git-version' function definitely should), but I'll comment it a bit

anyway.

Toggle quote (7 lines)

> @item @code{version}

> -The version of the package, as a string.

> +The version of the package, as a string. If there are no releases of

> +the package, or a unreleased version is desired, the version should

> +contain @code{VERSION-REVISION.COMMIT}. @code{VERSION} is

> +@c TODO: 0.0.0 or just 0 ?

@samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}} ... @var{VERSION}...

I think you should drop the "version 0" case altogether. I don't think

enforcing "0" or "0.0.0" does matter, and it adds noise to the

explanations.

Toggle quote (5 lines)

> +@code{0.0.0} or whatever the latest version is, and @code{REVISION} is

> +the revision of the Guix package (@code{0} if it is a new package),

> +whenever the package is updated to a newer version the revision should

> +also be bumped.

@var{REVISION}

I think you need to explain why bumping revision is needed.

Also, this is all specific to hash-based repositories. For example, SVN

uses monotonic revisions already, so none of the above applies to such

packages.

Toggle quote (6 lines)

> @code{COMMIT} is the @dfn{commit} or @dfn{changeset}

> +corresponding to the version, it should only contain 7 characters. If

> +the fetch method is @code{git-fetch} (@pxref{origin Reference}), there

> +is the @code{git-version} procedure that makes it easier to specify the

> +version.

@var{COMMIT}

Toggle quote (6 lines)

> +@example

> +(git-version "0.0.0" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")

> +@result{} "0.0.0-0.93818c9"

> +@end example

> +@end deffn

Here too, I think the special "0.0.0" case is misleading.

Maybe @lisp is more appropriate than @example.

Regards,

Nicolas Goaziou

Xinglu Chen wrote on 26 May 2021 16:07

Recipients:(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)(address . 48667@debbugs.gnu.org)

Message-ID:874kepy4ec.fsf@yoctocell.xyz

On Wed, May 26 2021, Nicolas Goaziou wrote:

Toggle quote (27 lines)> Hello,
>
> Xinglu Chen <public@yoctocell.xyz> writes:
>
>> * doc/guix.texi (package Reference): Describe how packages that lack a release
>> or are pinned to an unreleased version should specify the ‘version’ field.
>> Add documentation for the ‘git-version’ procedure.
>
> Thanks. 
>
> I don't know if all should be included in the manual (though I think
> the `git-version' function definitely should), but I'll comment it a bit
> anyway.
>
>>  @item @code{version}
>> -The version of the package, as a string.
>> +The version of the package, as a string.  If there are no releases of
>> +the package, or a unreleased version is desired, the version should
>> +contain @code{VERSION-REVISION.COMMIT}.  @code{VERSION} is
>> +@c TODO: 0.0.0 or just 0 ?
>
>   @samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}} ... @var{VERSION}...
>
> I think you should drop the "version 0" case altogether. I don't think
> enforcing "0" or "0.0.0" does matter, and it adds noise to the
> explanations.

Makes sense, users can probably that out on their own.

Toggle quote (13 lines)>> +@code{0.0.0} or whatever the latest version is, and @code{REVISION} is
>> +the revision of the Guix package (@code{0} if it is a new package),
>> +whenever the package is updated to a newer version the revision should
>> +also be bumped.
>
>   @var{REVISION}
>
> I think you need to explain why bumping revision is needed.
>
> Also, this is all specific to hash-based repositories. For example, SVN
> uses monotonic revisions already, so none of the above applies to such
> packages.

I am not familiar with SVN, but I will look into it.

Toggle quote (18 lines)>> @code{COMMIT} is the @dfn{commit} or @dfn{changeset}
>> +corresponding to the version, it should only contain 7 characters.  If
>> +the fetch method is @code{git-fetch} (@pxref{origin Reference}), there
>> +is the @code{git-version} procedure that makes it easier to specify the
>> +version.
>
> @var{COMMIT}
>
>> +@example
>> +(git-version "0.0.0" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
>> +@result{} "0.0.0-0.93818c9"
>> +@end example
>> +@end deffn
>
> Here too, I think the special "0.0.0" case is misleading.
>
> Maybe @lisp is more appropriate than @example.

Good point.

Thanks for the review!

Xinglu Chen wrote on 26 May 2021 16:57

[PATCH] doc: Expound on how to specify the version of a package.

Recipients:(address . 48667@debbugs.gnu.org)(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)

Message-ID:7a6a9bffa80fdfaa1e14015614cb638ff8cc7441.1622040691.git.public@yoctocell.xyz

* doc/guix.texi (package Reference): Describe how packages that lack a release

or are pinned to an unreleased version should specify the ‘version’ field.

Add documentation for the ‘git-version’ procedure.

---

Changes since v1:

* Remove the case for “version 0”.

* Use @var{} instead of @code{} when appropriate, and @lisp instead of

@example.

* Be more specific about what to set COMMIT to. Git/Mercurial and

SVN/Bzr should be handled differently.

doc/guix.texi | 26 +++++++++++++++++++++++++-

1 file changed, 25 insertions(+), 1 deletion(-)

Toggle diff (55 lines)diff --git a/doc/guix.texi b/doc/guix.texi
index e8b0485f78..9338136ebe 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -89,6 +89,7 @@ Copyright @copyright{} 2020 Jonathan Brielmaier@*
 Copyright @copyright{} 2020 Edgar Vincent@*
 Copyright @copyright{} 2021 Maxime Devos@*
 Copyright @copyright{} 2021 B. Wilson@*
+Copyright @copyright{} 2021 Xinglu Chen@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -6651,7 +6652,21 @@ This is the data type representing a package recipe.
 The name of the package, as a string.
 
 @item @code{version}
-The version of the package, as a string.
+The version of the package, as a string.  If there are no releases of
+the package, or a unreleased version is desired, the version should
+contain @samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}}.  @var{VERSION}
+is the version of the package, and @var{REVISION} is the revision of the
+Guix package (@code{0} if it is a new package).  Whenever the package is
+updated to a newer version the revision should also be bumped to reflect
+the fact that package has been updated.  If the fetch method for the
+package is @code{git-fetch} or @code{hg-fetch} (@pxref{origin
+Reference}), @var{COMMIT} should be the @dfn{commit} or @dfn{changeset}
+corresponding to the version, it should only contain 7 characters.  If
+the fetch method is @code{git-fetch}, there is the @code{git-version}
+procedure (see below) that makes it easier to specify the version.
+Packages which use @code{svn-fetch} or @code{bzr-fetch} should set
+@var{COMMIT} to the same value as the @code{revision} field in
+@code{svn-reference} or @code{bzr-reference}.
 
 @item @code{source}
 An object telling how the source code for the package should be
@@ -6757,6 +6772,15 @@ automatically corrected.
 @end table
 @end deftp
 
+@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
+Return the version string for packages using @code{git-fetch}.
+
+@lisp
+(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
+@result{} "0.2.3-0.93818c9"
+@end lisp
+@end deffn
+
 @deffn {Scheme Syntax} this-package
 When used in the @emph{lexical scope} of a package field definition, this
 identifier resolves to the package being defined.

base-commit: 3f2a4b098039bd374c76d524223de3c6c475f23e
-- 
2.31.1

Ludovic Courtès wrote on 5 Jun 2021 22:29

Recipients:(name . Xinglu Chen)(address . public@yoctocell.xyz)

Message-ID:87zgw4m4xa.fsf_-_@gnu.org

Hi Xinglu,

Xinglu Chen <public@yoctocell.xyz> skribis:

Toggle quote (4 lines)

> * doc/guix.texi (package Reference): Describe how packages that lack a release

> or are pinned to an unreleased version should specify the ‘version’ field.

> Add documentation for the ‘git-version’ procedure.

[...]

Toggle quote (18 lines)>  @item @code{version}
> -The version of the package, as a string.
> +The version of the package, as a string.  If there are no releases of
> +the package, or a unreleased version is desired, the version should
> +contain @samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}}.  @var{VERSION}
> +is the version of the package, and @var{REVISION} is the revision of the
> +Guix package (@code{0} if it is a new package).  Whenever the package is
> +updated to a newer version the revision should also be bumped to reflect
> +the fact that package has been updated.  If the fetch method for the
> +package is @code{git-fetch} or @code{hg-fetch} (@pxref{origin
> +Reference}), @var{COMMIT} should be the @dfn{commit} or @dfn{changeset}
> +corresponding to the version, it should only contain 7 characters.  If
> +the fetch method is @code{git-fetch}, there is the @code{git-version}
> +procedure (see below) that makes it easier to specify the version.
> +Packages which use @code{svn-fetch} or @code{bzr-fetch} should set
> +@var{COMMIT} to the same value as the @code{revision} field in
> +@code{svn-reference} or @code{bzr-reference}.

The text LGTM, but I think “package Reference” is the wrong place for

it: it’s the reference, whereas the text above is a guideline.

The “Version Numbers” section under “Packaging Guidelines” already

touches this topic. Perhaps we need to expand it and/or link to it from

“package Reference”, like:

@item @code{version}

The version of the package, as a string. @xref{Version Numbers}, for

guidelines.

The ‘git-version’ procedure could be documented in “Version Numbers”

too.

WDYT?

Thanks,

Ludo’.

Xinglu Chen wrote on 6 Jun 2021 11:09

Re: [bug#48667] [PATCH] doc: Expound on how to specify the version of a package.

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87k0n7740t.fsf@yoctocell.xyz

On Sat, Jun 05 2021, Ludovic Courtès wrote:

Toggle quote (44 lines)> Hi Xinglu,
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> * doc/guix.texi (package Reference): Describe how packages that lack a release
>> or are pinned to an unreleased version should specify the ‘version’ field.
>> Add documentation for the ‘git-version’ procedure.
>
> [...]
>
>>  @item @code{version}
>> -The version of the package, as a string.
>> +The version of the package, as a string.  If there are no releases of
>> +the package, or a unreleased version is desired, the version should
>> +contain @samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}}.  @var{VERSION}
>> +is the version of the package, and @var{REVISION} is the revision of the
>> +Guix package (@code{0} if it is a new package).  Whenever the package is
>> +updated to a newer version the revision should also be bumped to reflect
>> +the fact that package has been updated.  If the fetch method for the
>> +package is @code{git-fetch} or @code{hg-fetch} (@pxref{origin
>> +Reference}), @var{COMMIT} should be the @dfn{commit} or @dfn{changeset}
>> +corresponding to the version, it should only contain 7 characters.  If
>> +the fetch method is @code{git-fetch}, there is the @code{git-version}
>> +procedure (see below) that makes it easier to specify the version.
>> +Packages which use @code{svn-fetch} or @code{bzr-fetch} should set
>> +@var{COMMIT} to the same value as the @code{revision} field in
>> +@code{svn-reference} or @code{bzr-reference}.
>
> The text LGTM, but I think “package Reference” is the wrong place for
> it: it’s the reference, whereas the text above is a guideline.
>
> The “Version Numbers” section under “Packaging Guidelines” already
> touches this topic.  Perhaps we need to expand it and/or link to it from
> “package Reference”, like:
>
>   @item @code{version}
>   The version of the package, as a string.  @xref{Version Numbers}, for
>   guidelines.
>
> The ‘git-version’ procedure could be documented in “Version Numbers”
> too.
>
> WDYT?

Ah, I totally missed the “Version Numbers” section, it looks like it
already all the information I was looking for.  Since ‘hg-version’ was
just added, I will mention it as well.  :)

Xinglu Chen wrote on 6 Jun 2021 11:19

[PATCH] doc: Add reference for ‘git-ver

Recipients:(address . 48667@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:539a1a894dbbe25d5370b7bfb11006f736cbc875.1622971088.git.public@yoctocell.xyz

* doc/contributing.texi (Version Numbers): Document ‘git-version’ and
  ‘hg-version’.
* doc/guix.texi (package Reference): Reference ‘Version Numbers’ section for
  version naming guidelines.
---
 doc/contributing.texi | 22 +++++++++++++++++++---
 doc/guix.texi         |  4 +++-
 2 files changed, 22 insertions(+), 4 deletions(-)

Toggle diff (66 lines)diff --git a/doc/contributing.texi b/doc/contributing.texi
index 87719a4bbe..ee6cb97c8d 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -532,9 +532,11 @@ It is a good idea to strip commit identifiers in the @code{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
-@code{origin}s, though, to avoid ambiguities.  A typical package
-definition may look like this:
+kernel).  There are helper functions for doing this for packages using
+@code{git-fetch} or @code{hg-fetch} (see below).  It is best to use the
+full commit identifiers in @code{origin}s, though, to avoid ambiguities.
+A typical package definition may look like this:
+
 
 @lisp
 (define my-package
@@ -553,6 +555,20 @@ definition may look like this:
       )))
 @end lisp
 
+@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
+Return the version string for packages using @code{git-fetch}.
+
+@lisp
+(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
+@result{} "0.2.3-0.93818c9"
+@end lisp
+@end deffn
+
+@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
+Return the version string for packages using @code{hg-fetch}.  It works
+in the same was @code{git-version}
+@end deffn
+
 @node Synopses and Descriptions
 @subsection Synopses and Descriptions
 
diff --git a/doc/guix.texi b/doc/guix.texi
index eb64518a95..e71ec70859 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -89,6 +89,7 @@ Copyright @copyright{} 2020 Jonathan Brielmaier@*
 Copyright @copyright{} 2020 Edgar Vincent@*
 Copyright @copyright{} 2021 Maxime Devos@*
 Copyright @copyright{} 2021 B. Wilson@*
+Copyright @copyright{} 2021 Xinglu Chen@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -6657,7 +6658,8 @@ This is the data type representing a package recipe.
 The name of the package, as a string.
 
 @item @code{version}
-The version of the package, as a string.
+The version of the package, as a string.  @xref{Version Numbers}, for
+guidelines.
 
 @item @code{source}
 An object telling how the source code for the package should be

base-commit: 9caf7112ee50af26fbc4c1bd3c337f1f86b710af
-- 
2.31.1

Maxime Devos wrote on 6 Jun 2021 11:48

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:990f6b1bf7bcd9e78f212b8615e0201c48a81b2f.camel@telenet.be

Xinglu Chen schreef op zo 06-06-2021 om 11:19 [+0200]:

Toggle quote (14 lines)> +@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
> +Return the version string for packages using @code{git-fetch}.
> +
> +@lisp
> +(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
> +@result{} "0.2.3-0.93818c9"
> +@end lisp
> +@end deffn
> +
> +@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
> +Return the version string for packages using @code{hg-fetch}.  It works
> +in the same was @code{git-version}
> +@end deffn

Linguistic nitpick: about ‘It works in the same was @code{git-version}’: ‘in the same was’

seems ungrammatical to me. Should this have been something like

It works in the same way as @code{git-version}.

? (Remember to include the period.)

LGTM otherwise.

Greetings,

Maxime.

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYLyZ6RccbWF4aW1lZGV2

b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7neLAP9Z7/9lcMLFTeSV6pBOIRXPQjXg

QFJR/LLJyl6PjBxonwEAyAdYFrwPTNtBRIiKBgWXx/no6O54G8gQq9aKiW71VQ4=

=AAII

-----END PGP SIGNATURE-----

Xinglu Chen wrote on 6 Jun 2021 12:33

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:875yyr7052.fsf@yoctocell.xyz

On Sun, Jun 06 2021, Maxime Devos wrote:

Toggle quote (22 lines)> Xinglu Chen schreef op zo 06-06-2021 om 11:19 [+0200]:
>> +@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
>> +Return the version string for packages using @code{git-fetch}.
>> +
>> +@lisp
>> +(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
>> +@result{} "0.2.3-0.93818c9"
>> +@end lisp
>> +@end deffn
>> +
>> +@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
>> +Return the version string for packages using @code{hg-fetch}.  It works
>> +in the same was @code{git-version}
>> +@end deffn
>
> Linguistic nitpick: about ‘It works in the same was @code{git-version}’: ‘in the same was’
> seems ungrammatical to me. Should this have been something like
>
>    It works in the same way as @code{git-version}.
>
> ? (Remember to include the period.)

Indeed, I must have made a silly typo.

Xinglu Chen wrote on 6 Jun 2021 12:37

[PATCH v2] doc: Add refernece for ‘git-version ’ and ‘hg-version’.

Recipients:(address . 48667@debbugs.gnu.org)

Message-ID:7354a84803acc09bb64feb8b94519b9e5093d050.1622975743.git.public@yoctocell.xyz

* doc/contributing.texi (Version Numbers): Document ‘git-version’ and

‘hg-version’.

* doc/guix.texi (package Reference): Reference ‘Version Numbers’ section for

version naming guidelines.

---

Changes since v2:

* Fix typos

doc/contributing.texi | 22 +++++++++++++++++++---

doc/guix.texi | 4 +++-

2 files changed, 22 insertions(+), 4 deletions(-)

Toggle diff (66 lines)diff --git a/doc/contributing.texi b/doc/contributing.texi
index 87719a4bbe..3e2a9c8d2f 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -532,9 +532,11 @@ It is a good idea to strip commit identifiers in the @code{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
-@code{origin}s, though, to avoid ambiguities.  A typical package
-definition may look like this:
+kernel).  There are helper functions for doing this for packages using
+@code{git-fetch} or @code{hg-fetch} (see below).  It is best to use the
+full commit identifiers in @code{origin}s, though, to avoid ambiguities.
+A typical package definition may look like this:
+
 
 @lisp
 (define my-package
@@ -553,6 +555,20 @@ definition may look like this:
       )))
 @end lisp
 
+@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
+Return the version string for packages using @code{git-fetch}.
+
+@lisp
+(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
+@result{} "0.2.3-0.93818c9"
+@end lisp
+@end deffn
+
+@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
+Return the version string for packages using @code{hg-fetch}.  It works
+in the same way as @code{git-version}.
+@end deffn
+
 @node Synopses and Descriptions
 @subsection Synopses and Descriptions
 
diff --git a/doc/guix.texi b/doc/guix.texi
index eb64518a95..e71ec70859 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -89,6 +89,7 @@ Copyright @copyright{} 2020 Jonathan Brielmaier@*
 Copyright @copyright{} 2020 Edgar Vincent@*
 Copyright @copyright{} 2021 Maxime Devos@*
 Copyright @copyright{} 2021 B. Wilson@*
+Copyright @copyright{} 2021 Xinglu Chen@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -6657,7 +6658,8 @@ This is the data type representing a package recipe.
 The name of the package, as a string.
 
 @item @code{version}
-The version of the package, as a string.
+The version of the package, as a string.  @xref{Version Numbers}, for
+guidelines.
 
 @item @code{source}
 An object telling how the source code for the package should be

base-commit: 9caf7112ee50af26fbc4c1bd3c337f1f86b710af
-- 
2.31.1

Ludovic Courtès wrote on 6 Jun 2021 14:36

Re: [PATCH v2] doc: Add refernece for ‘git-vers ion’ and ‘hg-version’.

Recipients:(name . Xinglu Chen)(address . public@yoctocell.xyz)

Message-ID:87czszkw4k.fsf@gnu.org

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

Toggle quote (5 lines)

> * doc/contributing.texi (Version Numbers): Document ‘git-version’ and

> ‘hg-version’.

> * doc/guix.texi (package Reference): Reference ‘Version Numbers’ section for

> version naming guidelines.

Applied; thanks to the two of you!

Ludo’.

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 48667@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date