From: Hartmut Goebel <h.goebel@crazy-compilers.com>
To: guix-devel <guix-devel@gnu.org>
Subject: Contribute or create a channel?
Date: Fri, 1 Mar 2024 17:36:55 +0100 [thread overview]
Message-ID: <ed02e829-2ff5-5b0f-9849-61b48465f17b@crazy-compilers.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
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.goebel@crazy-compilers.com |
|www.crazy-compilers.com | compilers which you thought are impossible |
[-- Attachment #2: Type: text/html, Size: 2818 bytes --]
next reply other threads:[~2024-03-01 16:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 16:36 Hartmut Goebel [this message]
2024-03-01 18:16 ` Contribute or create a channel? Saku Laesvuori
2024-03-02 10:35 ` Hartmut Goebel
2024-03-01 21:13 ` Attila Lendvai
2024-03-01 22:35 ` Ricardo Wurmus
2024-03-12 13:18 ` Attila Lendvai
2024-03-12 16:56 ` Troy Figiel
2024-03-12 22:43 ` Carlo Zancanaro
2024-03-13 12:35 ` Attila Lendvai
2024-03-14 18:06 ` Josselin Poiret
2024-03-01 22:39 ` Ricardo Wurmus
2024-03-02 10:32 ` Hartmut Goebel
2024-03-04 8:32 ` Andreas Enge
2024-03-05 14:19 ` Hartmut Goebel
2024-03-05 22:34 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed02e829-2ff5-5b0f-9849-61b48465f17b@crazy-compilers.com \
--to=h.goebel@crazy-compilers.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).