> It is not unusual for us to get ScalaSteward PRs for jar versions that don't support Java 8 or that have API or behaviour changes that affect our builds. > Grouping the changes into one can mean we are delayed with updating the jars that are easy to upgrade.
Is this what we want though? If there is some trivial update i.e. some patch version that passes the test it makes sense to merge that PR right away and If we get failing PR's because a library was released with a newer JDK (as an example) we typically add a pin version and then we don't worry about it anymore (at least until we make JDK 11 the minimum version). Anyways I am not going to make a deal about this, I would say let's just wait a bit because I really do think what's happening now is temporary and we have already spent the effort in dealing with things like pinning dependency updates. On Sun, Apr 7, 2024 at 10:14 PM PJ Fanning <fannin...@apache.org> wrote: > > It is not unusual for us to get ScalaSteward PRs for jar versions that > don't support Java 8 or that have API or behaviour changes that affect > our builds. > Grouping the changes into one can mean we are delayed with updating > the jars that are easy to upgrade. > I have no issue with the failing PRs because they can prompt us to > investigate and produce a developer created PR that works instead. > > On Sun, 7 Apr 2024 at 21:51, Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > My counter argument to this is that the excessive amount of PR's being > > opened is largely > > a temporary issue, i.e. we got inundated with these PR's because 2 > > days ago I enabled > > scala-steward for the first time in a bunch of pekko repo's and those > > repo's haven't had their > > dependencies updated ever since the akka/pekko fork. > > > > I predict that going forward this will become less of an issue, I also > > have a tendency to prefer > > single atomic commits that are clear rather than grouping a lot of > > dependency updates together. > > > > That being said, for dependencies that get released in one go this > > makes sense, i.e. pekko-actor > > and pekko-stream will always get released at once so grouping those in > > a single PR is a definite > > benefit. > > > > On Sun, Apr 7, 2024 at 9:05 PM Samuele Resca <samuele.re...@gmail.com> > > wrote: > > > > > > Hi, > > > > > > at the moment scala-steward is opening a single PR for each dependency > > > update. Scala-steward provides a way of grouping multiple updates into > > > single PR[1]. I was thinking it might be valuable to explore this route. > > > Some benefits I can think of: less noisy, a single approval for the > > > patch/minor updates, less conflicts with multiple PRs opened. > > > > > > A proposal could be: > > > - Grouping all the patch updates into a single PR. I would expect patch > > > updates to be straightforward and have less chance to break anything in > > > our > > > CI step. > > > - Grouping all the minor updates into a single PR. Is this feasible? How > > > many minor updates break our CI? > > > - Keep all the major updates as separate PRs. There is an high chance that > > > major updates break something. Having them bundled together is not helping > > > the debugging. > > > > > > My main concern is that some dependencies don't strictly follow the > > > semver. > > > We might end up with a bundle of patch updates that are not only semver > > > patches. > > > > > > Any opinion or thought? Is it something is worth exploring? > > > > > > Samuele > > > > > > [1] > > > https://github.com/scala-steward-org/scala-steward/blob/main/docs/repo-specific-configuration.md?plain=1#L68 > > > > > > > > -- > > > > Matthew de Detrich > > > > Aiven Deutschland GmbH > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Alexanderufer 3-7, 10117 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > m: +491603708037 > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > -- Matthew de Detrich Aiven Deutschland GmbH Immanuelkirchstraße 26, 10405 Berlin Alexanderufer 3-7, 10117 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen m: +491603708037 w: aiven.io e: matthew.dedetr...@aiven.io --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org