On Fri, 31 Oct 2025 at 17:28, Gary Gregory <[email protected]> wrote: > > On Fri, Oct 31, 2025, 13:19 Matt Benson <[email protected]> wrote: > > > I also find the level of noise astounding here, and see no reason to pull > > in weekly updates when the release cadence of components is on the order of > > months or more likely years. Why not upgrade dependencies only when a > > component is nearing a release? > > > > My experience here and elsewhere is that this can cause release delays and > it can be much harder to upgrade from very old releases all at once. When > updating as you go, I find it simpler and also better for the FOSS > ecosystem at large where a dependency can then learn of incompatibility it > causes or bugs it's released before they calcify into a feature. The longer > you wait, the more likely you are to kick the can down the road "til after > the release" or "for the next release."
I agree that it can sometimes be a problem updating very old dependencies, but that is usually when they are many months or years old. Updating dependencies every week is overkill, and can result in multiple updates of the same plugin between releases. I think we should try quarterly updates, and see if there are any issues. When preparing for a release, one can easily use Maven to check for updates if necessary: $ mvn versions:display-dependency-updates $ mvn versions:display-plugin-updates > Hth, > Gary > > > > Matt > > > > On Fri, Oct 31, 2025, 11:34 AM Piotr P. Karwasz <[email protected] > > > > > wrote: > > > > > Hi Gary, > > > > > > On 31.10.2025 12:38, Gary Gregory wrote: > > > > Folks have proposed in the past creating a separate mailing list for > > > > Dependabot (or GitHub), but no one's done the work. > > > > > > > > The current setup works great for me, YMMV as it obviously does. I use > > > > GMail as my primary email client, which also works great. > > > > > > > > > I’m actually less concerned about the commit notifications on > > > `commits@commons` and more about the GitHub notifications themselves. > > > > > > For `commits@commons`, I can filter out most Dependabot noise using > > > `X-Git-Refname`, which leaves only the merge commits (and I’m hesitant > > > to filter those by subject). > > > > > > However, I still receive all Dependabot PRs as GitHub notifications, > > > unless I unsubscribe from all Commons repositories entirely. > > > > > > > > > >> - Centralize workflows in `commons-parent` (or a new `commons-actions` > > > >> repository) so that GitHub Actions updates happen only once. > > > > > > > > This would be painful as it creates delays and churn when you want > > > > something done. I only see pain for that one. > > > > > > > > We already have three (3!) different git repositories for > > > > build-related activities (parent, build plugin, release plugin), > > > > adding a 4th will make maintenance more painful. I could see merging > > > > the build and release plugin as actually useful. > > > > > > > > > In `logging-parent`, we have reusable workflows since two years ago. I > > > don’t recall many delays due to their updates. On the other hand, > > > coupling the `logging-parent` POM with the GitHub workflows feels > > > somewhat artificial, it would be cleaner to release workflows and other > > > artifacts separately. > > > > > > > > > >> - Avoid overriding Maven plugin versions unless there’s a strong > > reason > > > >> to do so. > > > > > > > > No way. This is part of participating in the Maven and general FOSS > > > > ecosystem. Eat out of your own kitchen, is the saying. > > > > > > > > > To clarify, I meant avoiding overriding plugin versions defined within > > > `commons-parent`, so we don’t get multiple PRs across repositories > > > upgrading the same Maven plugin independently. > > > > > > > > > >> - Use grouped Dependabot updates to upgrade multiple dependencies in a > > > >> single PR. > > > > > > > > What does this mean? I prefer granularity over big-bang PRs. > > > > > > > > > The grouping behavior is configurable, but even with broad grouping, I > > > doubt we’d see more than a handful of upgrades per PR. It’s more about > > > balancing granularity with signal-to-noise. > > > > > > > > > >> - Adjust Dependabot’s update schedule to match repository activity > > > >> (e.g., `monthly`, `quarterly`, or `yearly`). > > > > > > > > It was changed a while back from daily, which was too often, to > > > > weekly, which feels like a nice pace to me. Yearly? You must be > > > > joking. > > > > > > > > > Depending on the repository, I think even a *yearly* schedule could make > > > sense. Some Commons components receive only a handful of non-trivial > > > commits per year, so weekly Dependabot PRs provide no benefit. > > > > > > Dependabot automatically stops updating inactive PRs after roughly 60 > > > days, so another approach would be to set all repositories to `monthly` > > > updates and simply ignore Dependabot PRs for dormant ones. > > > > > > For single-dependency PRs, the update frequency doesn’t really affect > > > the total number of PRs (unless a dependency releases multiple versions > > > in a short time). However, for grouped PRs, the schedule matters more, > > > as it defines the size of the update window and how many upgrades are > > > bundled together. > > > > > > > > > >> - Move shared dependency management (such as test dependencies) into > > > >> `commons-parent`, where appropriate. > > > > > > > > That's already the case (JUnit, for example). > > > > > > > > > Sorry, I didn't notice. > > > > > > > > > >> Reducing unnecessary Dependabot churn will help us focus on changes > > that > > > >> truly matter. Note that Dependabot will still automatically create PRs > > > >> for security vulnerabilities in direct dependencies, regardless of > > other > > > >> settings. > > > > > > > > See the mailing list idea above, which no one in the past has seemed > > > > to care about enough to work on. > > > > > > > > > Technically, it’s already possible to redirect GitHub notifications > > > triggered by Dependabot to a separate mailing list. > > > However: > > > - Commits generated by Dependabot would still appear on `commits@`. > > > - Interactions with Dependabot (like PR merges) would still appear on > > > `notifications@`. > > > > > > Ultimately, I’d love to reach a setup where fewer than 50% of our > > > notifications are about dependency updates and more about meaningful > > > development activity. > > > > > > Piotr > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
