Hi bjc, On 31 July 2026 14:27:48 CEST, bjc <[email protected]> wrote: >Rutherther <[email protected]> writes: > >> I think doing minor releases would make sense for critical bugs and for >> security fixes to Guix itself. As long as this is kept, it should be >> fairly trivial to ensure the release works fine, since we're building on >> top of something that has already been released, just doing small fixes. >> >> What do you think of this idea? > >i think it's a good idea, but it requires, at least, a pretty big >process that we don't yet have. namely, support periods, and a bunch of >documentation around it.
I don't think so, I don't think it's necessary to complicate it like this. I would start by just doing it sporadically and seeing if it's possible to do it. For critical security bugs of Guix. Not like a promise that we possibly cannot deliver. Having support periods with promise on having security fixes delivered seems like a big commitment to me. > >is this gcd worthy? it seems like a big change to me to go from a purely >rolling distro to one which maintains multiple versions. > I do not think we should maintain multiple versions at current moment, we just amend the latest release so that users can download it, users typically download latest anyway. And distros could move easily. Supporting multiple version could again prove problematic. Note the situation that happened last year, where Debian removed guix from packages due to security fixes not being back portable to 1.4.0 easily, latest release at that time. Sometimes the code can get refactored so much that it's not possible to backport anymore. Someone in the thread mentioned fixing Emacs window manager, which possibly could also turn out hard if it needed different dependencies. So my proposal is currently to start small, try what we can. Whether it requires GCD I am not sure, but inclining to not. If we wanted to commit to supporting multiple last versions with some specific support periods, that would probably warrant a GCD. Rutherther >-bjc
