> I'm currently updating Tryton to version 7.0 and am wondering whether 
> it's better to contribute the change to Guix or to set up a channel for 
> Tryton.

As a general rule: it is always better to contribute a change instead of
maintaining a separate channel for it if the change could be accepted in
Guix.

>   * Bugfixes happens rather often and per-module, since they are
>     published even for smaller fixes. Upstream promises to not contain
>     functional changes or change requirements. Each bugfix could be
>     implemented as a graft, since .

I don't think it would make much sense to implement bugfixes as grafts
if the package isn't depended on by a huge number of other packages.

> Given this, it might be interesting to have three versions of Tryton 
> available: the two LTS versions and the latest version.
> 
> Now the idea is to provide a channel which provides a branch for each 
> LTS version and a "main" branch for the latest release. This would allow 
> to checkout the respective branch and refresh the packages of the 
> respective version semi-automatically.
> 
> OTOH in Guix, maintaining several version seems laborious.

It just requires a different updating method. The different versions can
just be defined as separate packages (see postgresql for an example) and
the user the defines which one they want to use. They can either refer
to the package variable directly in scheme (e.g. postgresql-15) or on
the command line with the name@version syntax (e.g. postgresql@15).

> Some more background-info:
> 
>   * Within each version, there is guarantee that the database schema
>     will not be changed. Anyhow between versions the db schema might
>     change, requiring manual migration steps.

This is the case with postgresql, too. (which is why I chose it as the
example before)

- Saku