You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MNT: using milestone as the one source of truth for backport automation #18814
A feature of meeseeks-dev, which we use to automate backports, is to create backport PRs based on the milestone rather than on a label (as we're currently doing). This is enabled simply by adding, e.g. on-merge: backport to v7.1.x to the milestone description. This would remove the need for most backport labels (except fo Manual Backport and Still Needs Manual Backport), and simplify developer workflows, removing one opportunity for mistakes in every PR where someone thinks of milestoning to a maintainance branch but forgets to add the corresponding label.
I initially assumed there could be a reason not to use this feature, but after almost 2 years working on astropy, I still haven't found one, so I'd like to propose this change, so if it's rejected I'll at least know why.
Reacted by Marten van Kerkwijk and Nathaniel Starkman
Milestone backporting was not a think when we introduced the bot, so that's probably why.
Also we used to maintain two backport branches when we had LTS, so we actually need 2 labels, and you can't apply 2 milestones. This is no longer an issue.
The only thing the milestone workflow cannot do is forward port, but I don't think the backport-main label works anyway, so I don't think this is a problem.
Overall, I am okay with this, but we will need to:
Also we used to maintain two backport branches when we had LTS, so we actually need 2 labels, and you can't apply 2 milestones. This is no longer an issue.
Ah, that makes a lot of sense, I didn't think about that ! (also I think I joined the project about the same time LTS was dropped)
I agree with your plan, with just one minor comment: I think the last two steps
Right after PR is merged, delete the defunct backport labels
And then apply said directives to the active backport milestone at the time
should be inverted. It'll be much easier to batch-triage all PRs from a label to a milestone and then remove the label.
Actually now we should wait until after #18986 has a path forward. All this talk about bringing LTS back might mean multiple release branches again, which would then make this workflow impossible to implement.
Actually @astrofrog proposed that backports to 7.2 should only be on-demand, as opposed to systematic, so maybe that fits perfectly with using labels in addition to milestones for exceptional PRs ?
So let's say we're at the point where main points to v8.1.dev, so we have to maintain both v8.0.x and v7.2.x. We milestone a PR to v8.0.1 and have the milestone backport it to v8.0.x. But then we also use the label to do a special backport to v7.2.x.
This is too confusing as now we have two different ways to backport.
Activity
pllim commentedon Nov 1, 2025
Milestone backporting was not a think when we introduced the bot, so that's probably why.
Also we used to maintain two backport branches when we had LTS, so we actually need 2 labels, and you can't apply 2 milestones. This is no longer an issue.
The only thing the milestone workflow cannot do is forward port, but I don't think the
backport-mainlabel works anyway, so I don't think this is a problem.Overall, I am okay with this, but we will need to:
Did I miss anything?
neutrinoceros commentedon Nov 2, 2025
Ah, that makes a lot of sense, I didn't think about that ! (also I think I joined the project about the same time LTS was dropped)
I agree with your plan, with just one minor comment: I think the last two steps
should be inverted. It'll be much easier to batch-triage all PRs from a label to a milestone and then remove the label.
pllim commentedon Nov 2, 2025
Okay but let's wait till v7.2 is out. I do not want this to interfere with the upcoming release activities. Thanks!
pllim commentedon Nov 26, 2025
Actually now we should wait until after #18986 has a path forward. All this talk about bringing LTS back might mean multiple release branches again, which would then make this workflow impossible to implement.
pllim commentedon Dec 3, 2025
Looks like people opted for "LTS lite" so probably means we cannot proceed with this? What do you think, @astrofrog ?
neutrinoceros commentedon Dec 3, 2025
yup, I think this means this issue will stay open until 8.1, at the earliest
pllim commentedon Dec 3, 2025
I dunno. Now that we have set the precedent, similar request might come up again and again. Maybe we should just stick with labels to stay flexible.
neutrinoceros commentedon Dec 3, 2025
Actually @astrofrog proposed that backports to 7.2 should only be on-demand, as opposed to systematic, so maybe that fits perfectly with using labels in addition to milestones for exceptional PRs ?
astrofrog commentedon Dec 4, 2025
Well it seemed the consensus today was to actually backport most fixes to 7.2.x rather than on demand
pllim commentedon Dec 8, 2025
So let's say we're at the point where
mainpoints tov8.1.dev, so we have to maintain bothv8.0.xandv7.2.x. We milestone a PR tov8.0.1and have the milestone backport it tov8.0.x. But then we also use the label to do a special backport tov7.2.x.neutrinoceros commentedon Dec 10, 2025
ok then let's just wait for when we're back to one backport branch