Question about changing versioning for TeX Live packages

Question about changing versioning for TeX Live packages

[Nicolas Goaziou via Development of GNU Guix and the GNU System distribution.]

Hello,

I'd like to change versioning for TeX Live packages. Currently, it
refers to a revision number in the upstream SVN repository, such as
70951.

I'd rather use tags from TeX Live releases, e.g., "2023.0", for at least
two reasons:

1. We don't need a granularity to the revision level for TeX Live
   packages;
2. Revision numbers are not very user-friendly, while tags are.

In a nutshell, my plan is to change version for all packages from
(revision) 66594 to the equivalent tag "2023.0". Unfortunately, as
mathematics go, 2023 is lesser than 66594. As a consequence, this may
introduce trouble when upgrading those packages. Therefore, my question
is the following: how could I proceed to make this version change as
smooth as possible for end-users?

Thanks for your input.

Regards,
-- 
Nicolas Goaziou

Re: Question about changing versioning for TeX Live packages

[Simon Tournier]

Hi Nicolas,

Sorry if this had been answered elsewhere, I have missed it.

On Sat, 15 Jun 2024 at 19:07, Nicolas Goaziou via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:

> I'd like to change versioning for TeX Live packages. Currently, it
> refers to a revision number in the upstream SVN repository, such as
> 70951.
>
> I'd rather use tags from TeX Live releases, e.g., "2023.0", for at least
> two reasons:
>
> 1. We don't need a granularity to the revision level for TeX Live
>    packages;
> 2. Revision numbers are not very user-friendly, while tags are.
>
> In a nutshell, my plan is to change version for all packages from
> (revision) 66594 to the equivalent tag "2023.0". Unfortunately, as
> mathematics go, 2023 is lesser than 66594. As a consequence, this may
> introduce trouble when upgrading those packages. Therefore, my question
> is the following: how could I proceed to make this version change as
> smooth as possible for end-users?

Well, if I read correctly, there is:

  guix/build-system/texlive.scm:

        (define %texlive-tag "texlive-2023.0")
        (define %texlive-revision 66594)

  gnu/packages/texlive.scm:

        (define %texlive-date "20230313")
        (define %texlive-year (string-take %texlive-date 4))


And the issue seems:

        (define-public texlive
           (package
            (name "texlive")
            (version %texlive-date)

and

        (define-public texlive-scripts
          (package
            (name "texlive-scripts")
            (version (number->string %texlive-revision))


Therefore, indeed it will be complicated to replace the ’version’ of
’texlive-scripts’ by something as ’2023’.

But why not a ’version’ as something as ’texlive’?  Or just 2023XY?
Where XY is something to determine as the month or something else.

Are we speaking a change only for the package field ’version’?  Or is
the discussion also about replacing the way to fetch from upstream?

Cheers,
simon

Re: Question about changing versioning for TeX Live packages

[Nicolas Goaziou via Development of GNU Guix and the GNU System distribution.]

Hello,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Well, if I read correctly, there is:
>
>   guix/build-system/texlive.scm:
>
>         (define %texlive-tag "texlive-2023.0")
>         (define %texlive-revision 66594)
>
>   gnu/packages/texlive.scm:
>
>         (define %texlive-date "20230313")
>         (define %texlive-year (string-take %texlive-date 4))
>
>
> And the issue seems:
>
>         (define-public texlive
>            (package
>             (name "texlive")
>             (version %texlive-date)

This is the monolithic TeX Live, which is not modified, and is therefore
off topic.

>         (define-public texlive-scripts
>           (package
>             (name "texlive-scripts")
>             (version (number->string %texlive-revision))
>
>
> Therefore, indeed it will be complicated to replace the ’version’ of
> ’texlive-scripts’ by something as ’2023’.
>
> But why not a ’version’ as something as ’texlive’?  Or just 2023XY?
> Where XY is something to determine as the month or something else.

Upstream uses version numbers such as "2024.2". I don't want to invent
another system.

> Are we speaking a change only for the package field ’version’?  Or is
> the discussion also about replacing the way to fetch from upstream?

I'm only changing the `version' field. For the record, "core-updates"
currently contains all TeX Live packages with their version switched to
"2024.2". In the worst case, maybe a notice in the guix news will be
sufficient.

Regards,
-- 
Nicolas Goaziou

Re: Question about changing versioning for TeX Live packages

[Simon Tournier]

Hi,

On Fri, 19 Jul 2024 at 18:38, Nicolas Goaziou via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:

> I'm only changing the `version' field. For the record, "core-updates"
> currently contains all TeX Live packages with their version switched to
> "2024.2".

Cool!  Nice it’s updated. :-)


>           In the worst case, maybe a notice in the guix news will be
> sufficient.

Hum, I am not convinced “guix news” would be enough.  Maybe we could
provide something that display a warning when upgrading a profile.

Cheers,
simon