@roidelapluie I can also help merge these dependencies PRs once this is merged 🙂

In my view, dependabot should be used in programs and not in libraries.

Updating dependencies of this library does nothing to update programs that use it, until they need a new feature from this library, and then they are forced to update whatever this library says. Libraries should not be in the business of forcing updates.

@bboreham I'm not sure what you mean. This library uses dependencies that need to be kept updated to get bug fixes and more importantly CVEs fixes.

I mean this has no practical benefit.
Only the dependencies built into programs (executables) matter. Changing this library does not affect any programs, unless they separately decide to update. So let’s let them do that and avoid the clutter here.

@bboreham In the Go ecosystem, it does matter, as downstream Go mod takes module versions included here as part of the update tree.

We already have dependabot on prometheus/client_golang.

Don’t forget sigv4 submodule

Downstream only takes an update if they specifically decide to update this library. It’s either a no-op or an accident, and I don’t want to promote either.

I’m fine with removing dependabot from all Prometheus libraries.

Except that's not how Go mod works in practice for indirect dependencies. It's not a noop or an accident, it's a core of how Go modules work. It doesn't matter if it's a library or an end-user binary repo. We need to maintain the versions we depend upon here. Automating it is necessary for maintainer sanity.

You are suggesting dependabot doesn’t work for indirect dependencies?

Nope, dependabot will not update indirect unless it's for a security vulnerability.