Add Support for Separate Pull Requests for Major, Minor, and Patch Version Updates

[ClemensRau1337]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

Currently, Dependabot does not provide a native way to separate Pull Requests for major, minor, and patch version updates within the same configuration. As a result, users cannot easily distinguish between different update types and may unintentionally merge major version updates that require more extensive testing and refactoring.

Feature Request:

I propose the addition of a feature that allows Dependabot to create separate Pull Requests for major, minor, and patch version updates. This would enable users to better manage updates by having dedicated Pull Requests for each update type, making it easier to prioritize and review changes based on their potential impact.

Example:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "Dependabot Minor/Patch"
    versioning-strategy: "increase"
    update-types: ["version-update:semver-minor", "version-update:semver-patch"]

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "Dependabot Major"
    versioning-strategy: "increase"
    update-types: ["version-update:semver-major"]

[jeffwidman]

Your suggested solution is effectively a duplicate of:

• https://github.com/dependabot/dependabot-core/issues/1778

However, I think the problem you're trying to solve is a little different... that's about running the update jobs on different schedules, but we'd still only have 1 PR per dependency open at any one time... versus here it looks like you want multiple PR's to float open.

There is value to doing incremental bumps rather than always jumping straight to latest, but from an implementation perspective that's difficult based on our current architecture, and frankly I'm not clear on the value... if you have a particular version you want to update to, then why not do it manually?

So I doubt we'd ever support more than one PR floating open.

As far as evaluating risk... have you seen https://github.com/dependabot/fetch-metadata ?

It'd allow you to add labels / control automation like automerge based on whether an update type is major / minor / patch. That feels like the better way to tackle this.

[yeikel]

There is value to doing incremental bumps rather than always jumping straight to latest, but from an implementation perspective that's difficult based on our current architecture, and frankly I'm not clear on the value...

A common scenario that could shed light here is when a library releases a new breaking version along with a non-breaking incremental patch for the previous versions. It's common to upgrade to interim versions while still keeping the breaking pull request in the backlog for further prioritization as breaking releases take more testing and work.

An instance of this scenario can be observed in graphql-java, where the breaking v20 release was made while maintaining v19.x simultaneously, with the v19.4 and v19.5 releases.

In this example, my team is not ready to upgrade to v20, but we manually monitored the project and upgraded to 19.4 and 19.5. It would be better if dependabot could detect this

[brcarp]

In this example, my team is not ready to upgrade to v20, but we manually monitored the project and upgraded to 19.4 and 19.5. It would be better if dependabot could detect this

Dependabot does have this in the sense that you can instruct Dependabot to ignore a major version (in its PR that upgrades to the next major version), and then it will stop doing that while continuing to produce minor/patch updates.

[yeikel]

In this example, my team is not ready to upgrade to v20, but we manually monitored the project and upgraded to 19.4 and 19.5. It would be better if dependabot could detect this

Dependabot does have this in the sense that you can instruct Dependabot to ignore a major version (in its PR that upgrades to the next major version), and then it will stop doing that while continuing to produce minor/patch updates.

We do not want to ignore the major version. In fact, it would be ideal to continue hearing about new releases of the major version as well

[Aaron-Ritter]

We have a very similar scenario we are currently testing:

  # Maintain dependencies for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    groups:
      prod-npm-minor-dependencies:
        dependency-type: "production"
        update-types:
        - "minor"
        - "patch"
      dev-npm-minor-dependencies:
        dependency-type: "development"
        update-types:
        - "minor"
        - "patch"
      prod-npm-major-dependencies:
        dependency-type: "production"
        update-types:
        - "major"
      dev-npm-major-dependencies:
        dependency-type: "development"
        update-types:
        - "major"

Reason behind this, all thought it might look strange in the beginning, we can clearly differentiate the relevance of dev and prod related packages from a build process perspective, and as mentioned earlier we want to know the major changes and the minor/patch changes separately as major usually require manual work and minor could be merged without any manual intervention.

The very generic "catch all" groups in this case, are here to start off with a simple but still sensible grouping. Which we then wanted to refine further depending on the created PRs. In addition it gives you a limited amount of PRs but with all possible package upgrades covered.

[asbjornu]

@jeffwidman,

There is value to doing incremental bumps rather than always jumping straight to latest, but from an implementation perspective that's difficult based on our current architecture

As @brcarp writes in https://github.com/dependabot/dependabot-core/issues/6957#issuecomment-1502043991, Dependabot seems to already have the architecture necessary to support this by being able to differentiate between update-types: [major, minor, patch].

and frankly I'm not clear on the value... if you have a particular version you want to update to, then why not do it manually?

With many dependencies, especially across different package ecosystems, it's hard to keep up with all releases. Being notified of a major release gives us time to plan for it and prioritize the changes required internally to accommodate the breaking changes in the dependency.

Separating major releases from minor ones gives us the ability to maintain the product while planning and working on the major version upgrade is happening in parallel on a separate branch.