Backport PRs

[FRidh]

We're getting good at keeping unstable rolling with the latest updates. A thing we're not so good at, is backporting fixes to our stable releases.

The question is, what should be backported? I would like to be able to assume that patch updates, assuming semantic versioning, won't cause any trouble. Under that assumption, I propose a test where the bot also generates PR's for stable.

Ideally, it would also create a link to commits already available on master, but this is not necessary.

[ryantm]

@FRidh Is this what you are proposing?

1. Assume semantic versioning if the version matches X.X.X
2. Make PRs to merge commits onto the release-18.03 branch where the change is X.X.A to X.X.B

Then, we need to update which branch it is twice a year. This sounds good and pretty doable.

[FRidh]

Yep, that's it. Though we might also want it only for X>=1 with the version X.Y.Z, because

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

That way we do it correct. Of course, upstream may still cause breakage.

[ryantm]

We now have a GitHub action that can do backports based on a label, but r-ryantm cannot add labels. @FRidh Do you feel like this feature is still necessary with the existence of that action?

[kini]

Can r-ryantm be made to add such labels, or is this a fundamental limitation? A problem with the auto-backport thing (as I see it) is that it's not smart enough to batch together multiple updates from master to backport them to a release branch. I.e.

1. foo is 1.0.0 on the master and release branches
2. foo is updated to 1.0.1 on master but nobody remembers to backport it to the release branch
3. foo is updated to 1.0.2 on master
4. someone attempts to add the backport label to the 1.0.2 bump PR, but the auto backporter fails because the diff from 1.0.1 to 1.0.2 doesn't cleanly apply to master where 1.0.0 is present.

If the nixpkgs-update bot were able to automatically apply the label on all eligible PRs, this would be avoided.

[delroth]

Me today on #dev:nixos.org:

<delroth> wanted: some way to tell r-ryantm that a given package should always have its updates backported to the stable 
<delroth> (this feature request brought to you by me noticing libcef on 23.05 is 4 versions of chromium behind)

Which is actually a point against using semver: chromium, libcef, firefox, etc. all bump their major version for each main update, and we should still backport those to stable pretty much always.

If we can't decide on a proper condition, could we hardcode a list somewhere of packages where the bot auto-applies the label on PR creation? :)