Reuse an open PR when updating a dependency instead of superseding it

[chrvadala]

Hi guys, I think that when there's a new bump release on a package that has an already opened PR, you can just upgrade that PR avoiding to open a new one.

Let's see this history, that happened in just 3 days: Bump webpack from 4.1.1 to 4.6.0 https://github.com/chrvadala/react-svg-pan-zoom/pull/99 Superseded by https://github.com/chrvadala/react-svg-pan-zoom/pull/101

Bump webpack from 4.1.1 to 4.7.0 https://github.com/chrvadala/react-svg-pan-zoom/pull/101 Superseded by https://github.com/chrvadala/react-svg-pan-zoom/pull/106

Bump webpack from 4.1.1 to 4.8.1 https://github.com/chrvadala/react-svg-pan-zoom/pull/106

[greysteil]

Makes sense to me - I don't think anyone's particularly attached to the old PRs. It's not a totally trivial change, but I should be able to get to it pretty quickly.

Thanks for the feedback!

[AndreaGiardini]

It makes perfect sense to me too, one of the advantages is also that the assignees/reviewers are kept

[php-coder]

It's not a totally trivial change, but I should be able to get to it pretty quickly.

@greysteil Is it already fixed?

[greysteil]

It's not - this is probably a full day's work on my side. I'll get to it, but have had a bunch of other higher priorities.

In the meantime, assignees and reviewers are now copied over from the old PRs. 😎

[lewisblackwood]

Another reason this would be nice to have is so that PR comments aren't lost when a new PR is opened. Sometimes I find myself leaving a PR comment to the effect of:

This is a major version change and we should test out the breaking changes manually! 😬

When the PR gets superseded by a minor version bump, the comment gets left behind. It would be handy if you could mark comments that should be carried over, but I guess maintaining a single PR is even better!

[waghanza]

This could also avoid unnecessary CI builds

I mean generaly CI run on each PR, and having 2 PRs make the work twice on CI side

[JacobEvelyn]

@greysteil are you still working on this? I have the exact same problem as @lewisblackwood—if I have extra context on a gem I'll leave a comment in the PR, but if the PR is superseded that comment gets lost forever.

[merwok]

Thanks @feelepxyz for keeping all these tickets open despite zealous stalebot! :slightly_smiling_face:

[fm-sys]

Again, more than two years have passed. Any progress on it, or is it at least still contained in the backlog?

[jurre]

I don't have anything to share in terms of roadmap, it's a feature we are interested in but it's unlikely that we'll be able to take it on in the near future.

One thing we'll need to think about (or just live with) is that we mention the version number in the branch that we open the PR from, this is potentially confusing. An option would be to not mention the version in branch names when this configuration option is enabled.

[Andre601]

One question that comes to mind for me is: Why was this system even made like this? Why was it decided that Dependabot should supersede an existing PR with a new PR instead of this behaviour of keeping everything in one PR itself? Was there some logistical reason, or some technical limitations back then (or even now)?

[KyleSanderson]

Ah jeez. Yeah, I've hit this too. The existing behaviour is literally insane and meets no expectation of usability. I'm certainly not going to put my customers through getting a ton of noise from Dependabot when there's no reasonable expectation of action behind it.

I'm happy to chat with whomever in product is open to a discussion, otherwise I'll have to turn down dependabot for my projects until such a time that it doesn't cause abusive notifications and issue counter increments in a repository.

[IamR3m]

Hey there. Any updates on it?

[omegazyadav]

Any plans to enable this feature ?

[BinToss]

I don't have anything to share in terms of roadmap, it's a feature we are interested in but it's unlikely that we'll be able to take it on in the near future.

One thing we'll need to think about (or just live with) is that we mention the version number in the branch that we open the PR from, this is potentially confusing. An option would be to not mention the version in branch names when this configuration option is enabled.

So, branches could instead be named "dependabot/npm/@types/node" and only superseded when the dependency's name changes.

Somewhat surprisingly, git allows the @ character in branch names.

[p0358]

And on top of that, it'd be nice if in the monthly grouped PRs, there was a way to issue a command to refresh the updates again to be the latest (instead of latest at the time of PR creation, which could be like 2 weeks ago for example).

[mvorisek]

This feature is hugely requested by the community, is here anyone with the skills needed to implement it?

[Elikill58]

This feature is hugely requested by the community, is here anyone with the skills needed to implement it?

I agree. 6 years after, it's already requested.

I checked if it were possible to do it myself. Sadly, I never used Ruby and it seems difficult for someone that never touch this repo, but is quick for dependabot's dev. I hope they will do it in 2024.

[LecrisUT]

Btw, renovate does support this feature. I got tired of waiting for this and I've migrated everything to that.

[p0358]

Looks like been fixed by supersede the old PR

???, the whole point of this issue from the very first comment is to stop doing exactly that

[KyleSanderson]

Looks like been fixed by supersede the old PR

???, the whole point of this issue from the very first comment is to stop doing exactly that

they're a bot.

I can't believe this hasn't been fixed. @jakecoffman are you going to Universe? Can we at least talk about this?