Hi, Rutherther <[email protected]> skribis:
> On February 19, 2026 4:17:17 PM GMT+01:00, "Ludovic Courtès" <[email protected]> > wrote: >>Hi, >> >>Tomas Volf <[email protected]> skribis: >> >>> 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? >> >>I think the spirit was that “-next” (as a package name) was for >>unreleased versions or version control snapshots; good examples of this >>are ‘guile-next’ and ‘emacs-next’. >> >>For released versions, we should keep the name unchanged IMO. Examples: >>[email protected], gcc-toolchain@15, openmpi@5, [email protected], etc. > > But then consider `guix shell python python-numpy`. That will not > work. It might be quite nonintuitive. So I am not sure it can be so > simple. Yes, and I agree it’s pretty bad. There was a proposal a few years back (by Lars-Dominik Braun IIRC) to add a package property that would somehow specify which version of a package should be the default. That way, (specification->package "python") would not necessarily return the package with the highest version number as it currently does, but could instead return the package that is marked as default. Perhaps we need to go in that direction? Ludo’.
