[Feature request] Opt out minor and patch versions

[bustikiller]

For organizations with many projects sometimes it is hard to keep track of all the dependency updates. I would like to get only updates for major & security releases (opt-out from minor and patch versions), configurable per project.

[feelepxyz]

@bustikiller ah yeah there's currently no way to disable all minor and patch releases. From experience upgrading to major releases without going through minor/patch releases usually makes the transition more painful as the minors sometimes introduce deprecations to make the update easier.

Not ideal but you could reduce some noise by ignoring minor versions of the most frequently updated dependencies from the PR with @dependabot ignore this minor - you would still hear about the next minor but silence all patch releases.

I'll keep this open to see if anyone else is also keen on this.

Thanks for the suggestion!

[Floppy]

@bustikiller perhaps you might reduce the noise while still getting the benefit of the updates by letting dependabot auto-merge minor updates? That's configurable per project, and separately for dev/production dependencies too.

[eddiej]

+1 for this feature request, the ability to ignore patch version updates would be great.

[NilsJPWerner]

+1 for ignoring patch updates. This would be great to configure in the config.yml

[repi]

We at Embark would love to be able to have Dependabot skip patch versions as well for our Rust projects. They create to much noise as multiple per day are updated and it is too much overhead to get a PR for each update, even if it is just weekly.

So for patch version updates we handle that manually ourselves through frequent cargo update rolled together updates multiple times per week. But want great Dependabot PRs for major and minor version upgrades.

[trevtrich]

Per what @Floppy mentioned, would auto-merging patch updates take care of the noise problem for folks, or is that not an option in your organization? We've found that auto-merging minor and patch after tests pass forces good testing practices primarily in that it forces you to rely on your tests. Like I mentioned, though, not possible in every org.

[bustikiller]

@richardson-trevor I understand the benefits of doing that, but this would only work if all dependencies followed semantic versioning. We have experienced patch version upgrades that broke production environments. For this reason, we prefer to test every dependency upgrade before going live. But it is not feasible for us to test every dependency upgrade if we have dozens every month.

I would prefer to have fewer dependency upgrades that we can properly test.

[trevtrich]

That's fair. We do shoot for our tests telling us that one of our deps is about to break production if there was a breaking change, but there are no-doubt cases that do slip through the cracks (or get stubbed out, which has been the source of our issues). In our situation we're able to kick out a new release to prod very quickly if this comes up, but this has only happened a few times in our course of about two years of moving to this mindset.

[trivikr]

Is this feature being worked on?
I tested dependabot in one of my personal repos, and too many PRs created was the only concern. Details in aws/aws-sdk-js-v3#280 (comment)

[greysteil]

Not at the moment. We're a tiny team and are prioritizing getting Automated Security Fixes working for all GitHub repos and fully integrating Dependabot into GitHub.

[trivikr]

Thanks @greysteil for the response

Is there an issue marked with good-first-issue or help-wanted for this request which contributors can look at (probably in dependabot-core)?
If not, can you create one with links to which code contributors can look at to provide this support?

[greysteil]

Frustratingly this one would need changes to our backend codebase, which isn't open source, rather than Dependabot Core.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[trivikr]

Pinging on this issue so that it's not closed by stalebot.
Looking at the comments and reactions, the community still would like to have this feature implemented.

[trivikr]

Dependabot has an option of opting out of minor version
Doc: https://dependabot.com/blog/ignoring-major-version-bumps/

However, it has to be done on each PR and can't be added as a default in the config

[itajaja]

This could be a low hanging fruit in my opinion. you already have the machinery for automerge updates. in fact, you can do

    automerged_updates:
      - match:
          update_type: "semver:patch"

but for some reason you can't do

    ignored_updates:
      - match:
          update_type: "semver:patch"

because update_type can't be used there. even this doesn't work

    allowed_updates:
      - match:
          update_type: "semver:patch"

because in this context update_type can only be all or security. if you already have the logic to drive auto updates, would be really that hard to add this to allowed_updates or ignored_updates? This would make our life so much easier 🙏

[trivikr]

In addition to what @itajaja mentioned, Dependabot allows us to ignore major/minor versions in PR by responding with "ignore this major/minor version"
Details: https://dependabot.com/blog/ignoring-major-version-bumps/

That means this feature is already there. They just need to make it configurable by users, which is not getting prioritized.

[benthorner]

This would be a great (per-repo) config option! Like @repi said: patch versions create so much noise, and usually add so little value, unless they actually fix something we're using.

[fent]

commenting to 👍 this issue

this is why I'm using both dependabot and greenkeeper. dependabot for security only updates, and greenkeeper for updating dependencies that don't fall into the given semver. which for most of mine means not creating PRs for minor and patch updates, only for major updates.

[trivikr]

I just came across update strategy increase_versions_if_necessary
Documentation: https://dependabot.com/docs/config-file/#available-update-strategies

Not sure how dependabot calculates version requirement, I'm trying it in one of my side projects

[cetinajero]

+1 for this, patch PR's create so much noise and so little value that it should be configurable to opt-out from those updates.

IMHO, this should be a valid config:

version: 1
update_configs:
  - package_manager: "javascript"
    directory: "/"
    update_schedule: "daily"
    ignored_updates:
      - match:
          dependency_name: "firebase"
          update_type: "semver:patch"

[Ir1d]

+1 for this

[BenGu3]

+1

Every day, we merge in 10+ patch updates. It'd be really nice to not have so much noise in many places, especially in our commit history.

[Luxiyalu]

+1 so this doesn't sink: especially that the internal workings are already there.

[saitho]

+1
I'd like to rebuild my Docker images only when a patch level changed.
Right now it updates php-fpm:7.2 to php-fpm:7.4 - I don't want that. ^^

[hackel]

This issue is even more critical now that the "ignore this major/minor version" command is gone in the new integrated Dependabot. I really don't want to clutter my commit history with a bunch of Dependabot management changes any time a package releases a new version I want to ignore. Github doesn't have any proper documentation I could find on the version specification format either, which doesn't seem to exactly match npm or similar tools.

[brcarp]

This behavior is perfect in my opinion, because it's based on two assumptions:

• there are always breaking changes in major releases, so developers' attention to new major releases is always needed
• there should be no breaking changes in patch/minor releases and developers' attention is needed only if CI build is failing (e.g. there might be accidental breaking changes in patch/minor releases)

I have similar feelings about the differences between major and minor/patch releases, but my preference is a bit let complicated than that from a workflow perspective: I'd like to have two different schedules for the same package-ecosystem with different update-types so that I can have one update-type run on the weekly schedule and the other run on the monthly schedule (or one dailiy one weekly if you prefer faster iteration), which better optimizes the opportunities to review major and minor updates on a periodic basis. My understanding is that this isn't possible at the moment because you can only have one update rule for a given package-ecosystem. (I haven't tested that specifically but it's the assumption I'm making based on the docs.)

[asciimike]

#1778 is the feature request you're seeking, and it's something we've thought about in the course of this, but haven't scheduled yet.

[asciimike]

https://github.blog/changelog/2021-05-21-dependabot-version-updates-can-now-ignore-major-minor-patch-releases/ is the official release of this feature (though you all have been using it all week ;)

Thanks for the patience with us on getting this shipped, as well as the feedback along the way. It's much appreciated.

I'm going to close this issue--if you've got additional issues or feature requests, please file the appropriate issue on this repo and we'll get to it soon!

[skjnldsv]

Now this: #2511
So we can all have proper configs on big github projects with multiple stable branches and get updates for patch dependencies 🙏

[pimjansen]

Im using this feature now but im getting "weird" responses. I have a very basic configuration overall to only allow patches on semver:

version: 2
updates:
  - package-ecosystem: composer
    directory: /
    target-branch: develop
    schedule:
      interval: weekly
    versioning-strategy: increase-if-necessary
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-minor", "version-update:semver-major"]

The thing is that im receiving these PRs:

• Bump laminas/laminas-soap from 2.8.0 to 2.9.0
• Bump sensio/framework-extra-bundle from 5.6.1 to 6.1.4
• etc

Below is the log output.

Targeting 'develop' branch under '/' directory
Using 'bump_versions_if_necessary' versioning strategy
Parsing dependencies information
Checking if doctrine/migrations 2.2.1 needs updating
Requirements to unlock own
Updating doctrine/migrations from 2.2.1 to 3.1.2
Submitting doctrine/migrations pull request for creation. Done (PR #5585).
Checking if laminas/laminas-soap 2.8.0 needs updating
Requirements to unlock own
Updating laminas/laminas-soap from 2.8.0 to 2.9.0
Submitting laminas/laminas-soap pull request for creation. Done (PR #5586).
Checking if sensio/framework-extra-bundle 5.6.1 needs updating
Requirements to unlock own
Updating sensio/framework-extra-bundle from 5.6.1 to 6.1.4
Submitting sensio/framework-extra-bundle pull request for creation. Done (PR #5587).
Checking if symfony/apache-pack 1.0.1 needs updating
No update needed for symfony/apache-pack 1.0.1
Checking if symfony/asset 5.1.7 needs updating

Is there anything that im missing here or?

Maybe @asciimike knows? Is this due the fact im using both major and minor?

[asciimike]

@pimjansen interesting, it should have some logs around ignoring versions (e.g. saying "foo is being ignored").

Would you mind removing versioning-strategy: increase-if-necessary and seeing if it changes anything? Curious if there's an odd interaction with both features 🤔

[pimjansen]

@pimjansen interesting, it should have some logs around ignoring versions (e.g. saying "foo is being ignored").

Would you mind removing versioning-strategy: increase-if-necessary and seeing if it changes anything? Curious if there's an odd interaction with both features 🤔

I tried but it fails with an error that auto is not a valid value though. Using composer as a package manager so guess it is or not implemented or wrong in docs. Since when i checked code the auto is not flagged as valid value

[asciimike]

Odd, as you say, according to https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#versioning-strategy it should be supported for composer. We'll look at this and get back!

[pimjansen]

Odd, as you say, according to https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#versioning-strategy it should be supported for composer. We'll look at this and get back!

Thanks, will also add some extra logs. Im using this extension though.

https://github.com/tinglesoftware/dependabot-azure-devops

Since there is no native integration for AzureDevops, this plugins seems the easiest way to go. Overall it boots the latest core docker image.

[asciimike]

@pimjansen if you're able to provide the org/repo as well, we can pull logs. If it's private/you don't want to share, feel free to email me at my username at github dot com.

[pimjansen]

@pimjansen if you're able to provide the org/repo as well, we can pull logs. If it's private/you don't want to share, feel free to email me at my username at github dot com.

It is not on Github so that would be hard. Let me copy the package files to a public repo and run it via actions to see if it handles the same

[pimjansen]

@asciimike i added a repo on Github but no idea how i can trigger it manually though to do a full run.
https://github.com/pimjansen/dependabot-semver

I see that 3 PRs are raised but those are security. Can you review that maybe?

Like mentioned earlier, since there is no native integration for DevOPS we use this layer (which is also available as extension like Github actions). https://github.com/tinglesoftware/dependabot-azure-devops
We have a pipeline that triggers the container and then it should normally update as expected. The layer is just a script like the Omnibus on top of the dependabot-core image.

[brcarp]

@pimjansen Have you confirmed whether the dependabot-core image itself is sufficiently updated to support the new configuraiton options?

[pimjansen]

@pimjansen Have you confirmed whether the dependabot-core image itself is sufficiently updated to support the new configuraiton options?

From which version is it in? The latest image there should be at 0.149.1 though which is just a few days old

[pimjansen]

@asciimike confirmed with the lib that not all was sent properly upstream to Dependabot. Sorry for all the noise.

[Nokel81]

We are using the github dependabot bot and event though we have configured it not to ignore major version bumps (https://github.com/lensapp/lens/blob/master/.dependabot/config.yml#L18-L21), we still are seeing them lensapp/lens#3019. That PR is 9 hours old, and the config was changes 16 days ago.

Any help would be appreciated.

[brcarp]

We are using the github dependabot bot and event though we have configured it not to ignore major version bumps (https://github.com/lensapp/lens/blob/master/.dependabot/config.yml#L18-L21), we still are seeing them lensapp/lens#3019. That PR is 9 hours old, and the config was changes 16 days ago.

Any help would be appreciated.

@Nokel81 I would try following the syntax as described in the docs, in other words:
update-types: ["version-update:semver-major"]
instead of

  update-types:
    - version-update:semver-major

[Nokel81]

Okay will do

[pimjansen]

Actually i think the docs reflect it as string as well and not as object:

update-types:
- version-update:semver-major

Vs

update-types:
- "version-update:semver-major"

However best to align 1 on 1 with the docs though

[Nokel81]

The actual problem was that I hadn't quoted the *, odd that it didn't complain.