On Wed, Dec 29, 2021, 9:21 AM Mark Thomas <ma...@apache.org> wrote: > On 29/12/2021 15:04, Gary Gregory wrote: > > On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins <chtom...@gmail.com> wrote: > > > >> Why not just run dependabot weekly. We move slowly enough that weekly > >> currently works. Until we can get more hands on the project, slower > comms > >> are indeed reasonable…right? > >> > > > > I would be OK with it once a week. > > I think the improvement resulting from moving to once a week will be > minimal. > > I get the desire to keep things up to date but the way dependabot is > currently working creates a lot of traffic on both issues@ and commits@ > That noise makes it much harder to follow any other activity that might > be happening in the project. I am finding it a lot more effort to keep > track of the Commons projects I am interested in. > > Most commons libraries have very few "real" dependencies. Most of the > dependencies are there to support testing or building. I would argue > that updates to test/build libraries are far less critical and low risk > to update en masse just before a release. > > I may look at applying local filters in the short term but that strikes > me very much as fixing the symptom rather than the cause and I don't > think it is efficient for every subscriber to have to do this if there > is an approach available that addresses the root cause. > > As an aside, we also need to keep repeatable builds in mind. Simply > defining a version dependency as "latest" (or anything other than an > explicit version) is going to be problematic. > > So, is there a way we could do something like the following with any > combination of dependabot and/or Versions Maven plugin and/or something > else? > > - dependabot like behaviour (daily check, separate PR) for dependencies > that are used (required or optional) at runtime > > - a weekly (or even monthly?) check for test libraries, build tools etc. > (i.e. everything that isn't a runtime dependency) that provides, > ideally, a single PR with one commit per update > > Emphasis on the "something like" the above. >
To jump into the discussion, I think these are sensible and constructive suggestions. Matt Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
