I want to clarify interpretation of packages Backporting criteria documented in CONTRIBUTING file.
One of the (many) features of nixpkgs which got me interested was the policy for stable branches backports - the fact that there is no fear to backport packages bug fix releases. But the real world experience is not that straightforward. There where different opinions and two of such backporting PRs where rejected.
My view on backporting bug fix releases is following:
Yes, there is always a chance that they will introduce new issues and it happens from time to time
But they usually fix much more issues than they introduce
I would very much prefer taking the risk and have version X.Y.5 with 50 bugs fixed + potentially very few new ones introduced, comparing to have X.Y.0 with 50 already known bugs.
We can always roll back
Whatās your opinion ?
This post was written with best intentions to clarify the process, I really donāt want to blame anybody and I very much appreciate all comments. Thank you
Thatās changing the āpatchā part of version, falling under the āpatch updatesā in criteria. But Iād say the tradeoffs depends on the particular package, e.g. some donāt follow a scheme close to semver, etc.
Do we guarantee the <pkg>.overrideAttrs interface stability when backporting to the release branch?
Specifically, does changes like ātreewide Python package pytestFlagsArray ā enabledTestPathsā allowed to backport even if pytestFlagsArray is already deprecated documentation-wise on the release branch?
There actually is mention of this in the pkgs/by-name/README.md, it doesnāt seem to get followed all too much though, especially because itās seemingly only mentioned here and not as a standard guideline. I agree with it being a backwards-incompatible change but again, itās not very clear whether this guidelines should apply to everything, or just by-name migrations.
IIUC, pkgs/by-name/README.md only mentions <pkg>.override, not <pkg>.overrideAttrs. Backward-incompatible changes to the <pkg>.override interface is currently considered a backward-incompatible change to Nixpkgs, but it doesnāt apply to the <pkg>.overrideAttrs interface.
Huh, I definitely misread the comment as .override and not .overrideAttrs, my mistake.
Thereās been a couple of times where Iāve seen this sort of thing PRād and merged, despite having been advised against it. Is there any due process to follow on how to handle that?
I havenāt seen an explicit documentation of the policy despite the frequent occurrence of the term āoverride interfaceā in the release notes. Maybe this is yet another example of the unspoken rules of Nixpkgs contribution.
