Hi,

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.

WDYT? I'm eager to learn about your thoughts.

Here is why I'm wondering:

 * Tryton consists of a client, a server and about 200 module/add-on
   providing business logic.
 *

   Tryton publishes a LTS version every 2.5 years. Two LTS versions are
   supported (currently 6.0 and 7.0) and bugfixes are backported there
   for 5 years.

 *

   Every 6 month a new release is crafted (x.2, x.4, x.6, x,8) which
   will get bugfixes for1 year. Releases typically provide new modules
   (which is why updating is of interest) , might change inputs and
   might require database updates.

 * 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 .

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.

Anyhow I'm unsure whether it's worth the effort maintaining three versions and whether I'll be able to keep three version up to date - esp. given that I don't have much automation for this.

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.
 * Debian as of now provides packages for 6.0 only (7.0 was released )


--
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goe...@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |

Reply via email to