Frank Thomas

> Maybe it's possible to support declarative dependency data source, like a yaml file .scala-steward.yml in the root of the repository? This reminds me of @alexarchambault's [_deps_](https://github.com/alexarchambault/deps/blob/master/WIP-README.md) which centralizes all...

That sounds similar to what we had before #724 and #757. I'm reluctant to make this behaviour available again via some kind of configuration options because each option makes it...

I think this comment is relevant here: https://github.com/fthomas/scala-steward/pull/724#issuecomment-558668425. I'm open to adding a simple repository-specific configuration that just short-circuits this [hasConflicts](https://github.com/fthomas/scala-steward/blob/master/modules/core/src/main/scala/org/scalasteward/core/nurture/NurtureAlg.scala#L205-L208) check and always returns `true`.

We're already using sbt-ci-release. Maybe you should just try running the `scripts/release.sh` and see if everything works. :-)

Btw, https://github.com/scala-steward-org/scala-steward/issues/2486 lists what I've done previously to publish new versions.

> error: gpg failed to sign the data error: unable to sign the tag Looks like signing the tag didn't work.

I would prefer creating the tag via the release script so that we all use the same procedure for creating releases.

@exoego I just published 0.15.0 myself. Feel free to try it again with 0.16.0 as soon as a new PR is merged.

One idea to fix this is to pair the URL we want to show in the PR body with another proxy URL that points to the same resource but returns...

It seems to me that this will only delay subsequent PRs with the same changes to the next run. If Scala Steward creates a PR for an update and that...