diff mbox series

[bug#66148,v2,2/2] doc: Mention it when we were pulled.

Message ID dae1caae6a5355977e6fc0d94b0c16278be206d8.1694908800.git.me@tobias.gr
State New
Headers show
Series [bug#66148,v2,1/2,Sloppy,PoC] self: Use a more meaningful VERSION string for manuals. | expand

Commit Message

Tobias Geerinckx-Rice Sept. 17, 2023, midnight UTC
Now that we use the latest release VERSION even for pulled Guixes,
make it abundantly clear that this is a later build.

* guix/self.scm (info-manual): @set the PULLED flag in version.texi.
* doc/guix.texi (Top): Honour it.
---
 doc/guix.texi | 5 +++--
 guix/self.scm | 4 ++++
 2 files changed, 7 insertions(+), 2 deletions(-)

Comments

Ludovic Courtès Sept. 22, 2023, 1:17 p.m. UTC | #1
Hi!

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Now that we use the latest release VERSION even for pulled Guixes,
> make it abundantly clear that this is a later build.
>
> * guix/self.scm (info-manual): @set the PULLED flag in version.texi.
> * doc/guix.texi (Top): Honour it.

Yeah, great initiative!

I wonder if we could avoid adding code to (guix self).  For instance,
we could have (guix self) leave ‘VERSION’ undefined and in the manual
we’d have those @inlineifset{VERSION, version @value{VERSION}, revision
from @command{guix pull}}.

How does that sound?

Ludo’.
Tobias Geerinckx-Rice Sept. 22, 2023, 2:51 p.m. UTC | #2
Sounds good, but my main objection is to the bogus URLs and image file names.

I considered a simpler @set RELEASE 1.4.0 that is 'manually' updated on each stable & rc release, but prefer automation.  However, I'm not familiar with the work of a release manager.  If they are expected to run some script anyway, that could work.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.
Ludovic Courtès Sept. 25, 2023, 2:57 p.m. UTC | #3
Hi,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Sounds good, but my main objection is to the bogus URLs and image file names.

Oh right.

> I considered a simpler @set RELEASE 1.4.0 that is 'manually' updated on each stable & rc release, but prefer automation.  However, I'm not familiar with the work of a release manager.  If they are expected to run some script anyway, that could work.

Yes, it should definitely be automated.

So I guess we need something like you proposed.  However, I’d go for
plain ‘read’ + ‘match’ instead of regexps.  It should be good enough,
and we can make it fail-safe.

How does that sound?

Thanks,
Ludo’.
Simon Tournier Sept. 26, 2023, 5:59 a.m. UTC | #4
Hi,

On Mon, 25 Sep 2023 at 16:57, Ludovic Courtès <ludo@gnu.org> wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>
>> Sounds good, but my main objection is to the bogus URLs and image file names.
>
> Oh right.
>
>> I considered a simpler @set RELEASE 1.4.0 that is 'manually' updated
> >on each stable & rc release, but prefer automation.  However, I'm not
>> familiar with the work of a release manager.  If they are expected to
>> run some script anyway, that could work. 

And VERSION also leads to broken URL, as with:

    @url{@value{BASE-URL}/guix-system-vm-image-@value{VERSION}.x86_64-linux.qcow2}

Cheers,
simon
Tobias Geerinckx-Rice Sept. 29, 2023, 11:42 a.m. UTC | #5
Hi!

On 2023-09-25 16:57, Ludovic Courtès wrote:
> plain ‘read’ + ‘match’ instead of regexps.  It should be good enough,
> and we can make it fail-safe.

You tease.  How?

Fail-safe is key: I'm not a READ guru, I just know it throws on unknown 
#-forms by default, which is unacceptable here.

> How does that sound?

Alluring.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.
Ludovic Courtès Oct. 1, 2023, 3:14 p.m. UTC | #6
Hello!

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> On 2023-09-25 16:57, Ludovic Courtès wrote:
>> plain ‘read’ + ‘match’ instead of regexps.  It should be good enough,
>> and we can make it fail-safe.
>
> You tease.  How?
>
> Fail-safe is key: I'm not a READ guru, I just know it throws on
> unknown #-forms by default, which is unacceptable here.

In practice, the only hash extension we care about is that of (guix
gexp).  If we have it loaded, we can ‘read’ the thing and be done with
it.

Now, I guess I’m starting to understand: we can’t easily have (guix
gexp) loaded in there, right?

In that case, for the purposes of extracting the ‘guix’ version number,
would it be enough to have a simplified version of those extensions (the
‘read-hash-extend’ at the bottom of gexp.scm)?… Hmm, I’m not so sure
anymore…

Ludo’.
diff mbox series

Patch

diff --git a/doc/guix.texi b/doc/guix.texi
index 39088b954b..c959cff1a1 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -166,8 +166,9 @@ 
 @node Top
 @top GNU Guix
 
-This document describes GNU Guix version @value{VERSION}, a functional
-package management tool written for the GNU system.
+This document describes GNU Guix @inlineifset{GUIX-PULLED, from a
+@command{guix pull} after the release of} version @value{VERSION}, a
+functional package management tool written for the GNU system.
 
 @c TRANSLATORS: You can replace the following paragraph with information on
 @c how to join your own translation team and how to report issues with the
diff --git a/guix/self.scm b/guix/self.scm
index 2d11dd47a4..81c5c722e0 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -469,6 +469,10 @@  (define (info-manual source)
                                     v)
                                   "0.0-git")))
                 (format output "\
+@c There's no Texinfo command to test whether @value{UPDATED} ends in 1970 and
+@c tweak the intro to guix.texi accordingly, so we add this Guix-specific flag.
+@set GUIX-PULLED true
+
 @set UPDATED 1 January 1970
 @set UPDATED-MONTH January 1970
 @set EDITION ~a