Skip to content

MNT: using milestone as the one source of truth for backport automation #18814

Open

Description

@neutrinoceros

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.

Activity

  1. pllim commented on Nov 1, 2025

    @pllim
    Member

    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:

    • Set a switchover date
    • Issue PR to update dev docs and have it merged on switchover date -- DOC: Backport with milestone instead of labels #18829
    • Right after PR is merged, apply said directives to the active backport milestone
    • Then delete the defunct backport labels at the same time

    Did I miss anything?

  2. neutrinoceros commented on Nov 2, 2025

    @neutrinoceros
    ContributorAuthor

    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.

  3. pllim commented on Nov 2, 2025

    @pllim
    Member

    Okay but let's wait till v7.2 is out. I do not want this to interfere with the upcoming release activities. Thanks!

  4. added this to the v8.0.0 milestone on Nov 3, 2025
  5. pllim commented on Nov 26, 2025

    @pllim
    Member

    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.

  6. pllim commented on Dec 3, 2025

    @pllim
    Member

    Looks like people opted for "LTS lite" so probably means we cannot proceed with this? What do you think, @astrofrog ?

  7. neutrinoceros commented on Dec 3, 2025

    @neutrinoceros
    ContributorAuthor

    yup, I think this means this issue will stay open until 8.1, at the earliest

  8. pllim commented on Dec 3, 2025

    @pllim
    Member

    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.

  9. neutrinoceros commented on Dec 3, 2025

    @neutrinoceros
    ContributorAuthor

    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 ?

  10. astrofrog commented on Dec 4, 2025

    @astrofrog
    Member

    Well it seemed the consensus today was to actually backport most fixes to 7.2.x rather than on demand

  11. pllim commented on Dec 8, 2025

    @pllim
    Member

    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.

    1. This is too confusing as now we have two different ways to backport.
    2. Now the milestone is lying to us.
  12. neutrinoceros commented on Dec 10, 2025

    @neutrinoceros
    ContributorAuthor

    ok then let's just wait for when we're back to one backport branch

  13. modified the milestones: v8.0.0, v9.0.0 on May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions