To be honest, I rarely update dependency versions Log4j. I recently did it for
the Spring support to pick up some fixes that were required. But I am just not
sure how we can tell a user that a current version of Log4j is compatible with
an older version of a component if we are only using the la
I’ll say that we also use Dependabot and some custom bot at work for
dependency updates, and I’m one of the evangelists, but it’s to ensure that
things get security updates which would otherwise clog up the resources of
the limited number of engineers working on security in the first place. I
somet
On Thu, Sep 17, 2020 at 8:49 PM Ralph Goers
wrote:
> I very much like all the emails due to dependabot. Furthermore, if it is
> going to create 25 PRs then it also needs to create Jira issues and include
> updates to changes.xml, otherwise it just creates a lot of work.
> Furthermore, I have neve
I tend to prefer using the latest versions by default, and using “break glass”
overrides to back versions down. I wouldn’t want our users to be stuck on older
log4j versions due to unnecessarily loose version constraints from projects
like Spring. If we define the minimum version, consumers are
I’d like to use it if we can configure it to do those things. Otherwise, we
could disable it and find an alternative bot or service that does allow us
to customize the actions it performs. There’s plenty of other services that
scan dependencies, some of which have free SaaS versions for OSS.
On Th
I very much like all the emails due to dependabot. Furthermore, if it is going
to create 25 PRs then it also needs to create Jira issues and include updates
to changes.xml, otherwise it just creates a lot of work. Furthermore, I have
never been in favor of updating dependencies versions without
