Hi, this is nothing new and clearly has been the case for a number of packages in Guix.
For packages that have not of dependencies (say 300 or more) updating to new versions have been increasingly difficult, as lots of rebuilds needed and Guix QA is really overwhelmed (it seems). For other reasons like API compatibility some such packages exist in a state of multiple versions, with old versions sticking around to satisfy other packages depending on them. Example: samba and samba-next Maybe this can be generalized for packages with lots of dependencies, say for any package A with 300 (or 1000) dependencies, when upgrading to a new version, add that as A-next so existing A is not touched. Then A-next can be added without any dependencies, and Guix QA just needs to check if A-next builds. Then people working on any package depending on A can move that package to depending on A-next later independently. This avoid triggering world rebuilds. And A's dependents migrate at their own flow. Or a feature branch can still be used for these migrating dependencies but A-next can be added to master first and made available, without waiting for a feature branch to be merged Is this workable idea?
