Ability to club dependencyUpdates for a repo in a single PR

[anilkumarmyla]

This is a similar ask like #412 but suggest upgrades for a repo in a single PR.

[fthomas]

I don't like bundling updates into one PR mostly because it complicates the implementation of Scala Steward and would raise a set of new problems / questions for which I don't see good solutions. Here are a few issues I see:

• The set of updates that are included in such a PR depend on the time it was created. A second later there might be another dependency with an update which would have been included in the PR. On the next Scala Steward run, should this dependency be included in this PR or should a new one be created? Would the new one include the updates of the previous PR?

• We loose the ability to detect if there is already a PR for a particular update. Currently it is possible to delete the complete persistent state Scala Steward created and run it again and it would find the PRs it created before again and would not create duplicated PRs for the same update. We can do this because each update corresponds to a distinct branch name which we can search for. I don't see how this could be done when updates are bundled in one PR.

• A lot of new code that needs to be maintained. The current code assume that one update corresponds to one branch and one PR. A bundle PR would break that assumption and there needs to be code that accounts for that. I don't think that the benefits of this feature outweigh the maintenance costs.

[anilkumarmyla]

I agree we should not club dependency updates for a repo in a single PR. It will be nice to have a tooling where a command like sbt doDependencyUpdates would auto-magically update all possible pending updates in a repo, which developers can test and raise their own PRs. scala-steward might not be the right fit here. Feel free to close.

[mcanlas]

Keyword stuffing: combining combined aggregate aggregated

[fthomas]

Closing because of the reasons given above.