Stable branch backporting criteria

Development
1

Hi all,

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:

  1. Yes, there is always a chance that they will introduce new issues and it happens from time to time
  2. But they usually fix much more issues than they introduce
  3. 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.
  4. 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

2 Likes
2

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.

3

Thanks @vcunat , I am talking about packages which mostly semver scheme.

Any more opinions ?