search

dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.65k stars 1k forks source link

Add Support For Breaking Change In Conventional Commit Messages #10221

Open fergoid opened 2 months ago

fergoid commented 2 months ago

Is there an existing issue for this?

Feature description

When managing dependencies on major version for our code base we perform automated version bumping. Since we want to indicate to our own consumers that there may be an update that requires them to make a change in their code being able to convey this in the pull request commit message will help (as we will do a major version bump on our own code as a result).

With conventional commits this can be done in one of two ways

fix(scope)!: some commit message

or

fix(scope): some commit message

BREAKING CHANGE: this will break stuff

So there are two ways we could go, make the change specific to breaking changes with a breaking change option or be more flexible and add a commit footer option. The latter would allow dependabot users to use the footer for other purposes as well as breaking changes.

    commit-message:
      prefix: "fix"
      include: "scope"
      footer: "BREAKING CHANGE: major version update"
yeikel commented 2 months ago

I am a bit confused with this change. Why would a fix be considered a breaking change?

Also, see #1460

fergoid commented 2 months ago

According to conventional commit spec a fix can be a breaking change. In any case it was for illustration purposes. However I did find a workaround. Just set the commit prefix configuration to ‘fix(deps)!: ‘.

yeikel commented 2 months ago

According to conventional commit spec a fix can be a breaking change. In any case it was for illustration purposes. However I did find a workaround. Just set the commit prefix configuration to ‘fix(deps)!: ‘.

Definitely, my wording was poor.

What I meant is that a minor version bump from a fix from a third party dependency does not necessarily mean that it is a breaking change to the project that receives the upgrade

I am still a bit confused about what your actual feature request is given the alternative that you found

Could you please share concrete examples from both the point of view of the dependency being upgraded and the project that receives the update?