how many PRs? one per run? just one?

[StefanKarpinski]

It would be nice if this would group stdlib updates and create a single PR for each batch, in case there are dependencies between the updates (e.g. JuliaLang/julia#38808).

But here's another thought: what if this always pushed to the same branch? Hear me out. If you push to a branch that already has an open PR, then it just updates that PR. Which is fine since if someone updates a bump PR when an older one is already open, we want to close the old one anyway; why not just update it instead? What happens if you push to a PR branch after that PR has been merged? Works just fine and you can create a new PR from the same branch. This would enforce that there is at most one stdlib bump PR at a time.

One tweak that would be needed with that approach is that you'd want stdlib bumps to be done relative to what's already in that branch: i.e. if an old bump updates a stdlib and you trigger a new bump that doesn't include that stdlib, you don't want to accidentally roll it back to what's on master since someone else asked for it to be bumped already. Perhaps the logic could be this: if there's no open bump PR (i.e. the branch doesn't exist or the PR's been closed), then a new bump starts from the master state of stdlibs; if there's an open bump PR, then a new bump starts from there, re-bumping what's requested.

[DilumAluthge]

This would enforce that there is at most one stdlib bump PR at a time.

I think this is the right approach.

[StefanKarpinski]

A simpler alternative would be that it just bumps all stdlibs to the latest every time. Then you don't have to worry about the current state of the branch: you always just generate a commit relative to master that bumps everything and force push it.

[DilumAluthge]

A simpler alternative would be that it just bumps all stdlibs to the latest every time. Then you don't have to worry about the current state of the branch: you always just generate a commit relative to master that bumps everything and force push it.

Yeah this would certainly be the easiest approach.

I guess the question is: is there ever a case in which you explicitly don't want to update a stdlib?

[StefanKarpinski]

This is kind of a policy decision. While I can imagine a contrived situation where we don't want that, there's a case to be made that if you didn't want it on Julia master, you shouldn't have merged it to master in the stdlib. I would be inclined to go all or nothing with this and see how that goes. My workflow has generally been to bump stdlibs to Julia master first and only after they've proven to be unproblematic there for a while, tag a release of the stdlib.

[DilumAluthge]

I guess with ArgTools, we are currently in that situation. I.e. we don't want ArgTools master to be on Julia master.