On 2026-02-13, Tomas Volf wrote: > right now there is no uniformity on whether a teams uses -next for a > unreleased, unstable version of packages (e.g., guile-next) or whether > teams use the same package name for unreleased, unstable versions of > packages (e.g., go). That is confusing for the user (well, at least I > was confused). > > When I asked about this, I was told there are no rules, so basically > packager can do whatever. Before I start the GCD process to define > those rules, I would like to "feel the room" and see whether the > community considers this topic a debate-worthy (so that I do not waste > the time writing the document and bothering people needlessly). > > Since we are a distribution, users should be able to have the same > expectations across all our packages, and not having to inspect how each > team does things, as long as they are just "using" Guix. So there > should be clear expectation what `guix install PKG' will give you. Will > it be a stable, released version? Will it be a latest release > candidate? Will it be a git snapshot of a yet-to-be-release-candidate > version? Therefore I think we should have a common naming pattern.
First step, of course, is to get all the upstreams to be consistent... :) In all seriousness, though... One projects git snapshots are going to be whatever some developer happened to push that day, maybe another project pushes first to get things tested in CI, and another project might have rigorous regression testing before it is even allowed into the public facing git repository. Similar things for releases, release candidates, alpha releases, beta releases, etc. though one would *hope* the standards are a little higher, it is not all that uncommon for a project to release some new version, only to have a rapid succession of fixup point releases in the following hours, days and weeks... or even worse, deleting the old version and just uploading a fixed version with the same version!!! There are many different upstream workflows... some projects never make realeases of any kind! Some versions get stuck for whatever reason (GRUB 0.9x comes to mind, or GRUB2 1.9x)... and remember that project Guix which had no releases for over two years? :) Some projects maintain multiple concurrent stable versions (e.g. linux upstream currently has 6.19.x, 6.18.x, 6.12.x, 6.6.x, 6.1.x, 5.15.x and 5.10.x) ... which one is the current version? old version? next version? penultimate version? median version? :) ... we even still have 6.17.x in guix(though not for long), which is EOL for almost two months, should that follow some convention? I recently updated a version of diffoscope in guix to a git snapshot, simply to pull in a fixed test which was the only code change. This seemed less disruptive to me than importing the patch into guix, only to drop the patch a week later when it was included in an upstream release. I vaguely remember also discussing nss vs. nss-next vs. nss-rapid when reviewing librewolf updates... and was eventually convinced nss-rapid made sense, as "-next" really didn't seem to be consistent with other "-next" packages in guix... There are also considerations of where a package sits on the dependency graphs, too... guix often lags on things like upstream glibc, gcc and python (and even to some degree, guile!?!) versions, for example, so as to avoid rebuilding the world too often... what does "next" even mean when guix is several significant versions behind upstream? To work around that, in some cases, folks use a versioned package name, which in one sense is a strenth of guix's model (e.g. being able to have multiple concurrent versions), but also I suspect leaves some housecleaning for "someday" to be done... and the cobwebs are accumulating. :) > So, the question is, do we want some rules for the naming and versioning > of the packages (e.g., $pkg is any *released* version, and $pkg-next is > *any* version, often newer, possibly git snapshot or a release > candidate)? Or do you feel this would be governance overreach, it > should stay strictly up to the packagers and we should just document > that users who do not want release candidates should just always pin > versions of everything? So, while I agree it would be nice to work towards internal consistency and have been confused by this issue more than a few times, I think at best maybe some better guidelines about this sort of thing could be helpful. It is also important to have significant room for discretion of the commiters, teams, maintainers, etc. ... otherwise we risk trying to impose simple rules on a complex world that we have little direct control over. ... Or even worse, perhaps overly complex rules that still fail to capture the reality of the world! Apparently I have opinions. :) live well, vagrant
signature.asc
Description: PGP signature
