Closed theNailz closed 2 years ago
it seems that dependabot has a general issue with the caret: in my Python project I have ^0.8
which allows versions >= 0.8.0 && <1
, nevertheless, I get a PR with the requested change:
-pygls = {version = "^0.8", optional = true}
+pygls = {version = ">=0.8,<0.10", optional = true}
to allow pygls-0.9
, see https://github.com/cp2k/cp2k-input-tools/pull/12
I believe we are experiencing this issue as well.
We have in our package.json: "graphql": "^14.7.0",
But dependabot is opening a PR to change this to: "graphql": "^15.3.0",
Not sure how to find dependabot logs but would be happy to attach them if someone can tell me where they are.
I believe we are experiencing this issue as well.
We have in our package.json:
"graphql": "^14.7.0",
But dependabot is opening a PR to change this to:"graphql": "^15.3.0",
Not sure how to find dependabot logs but would be happy to attach them if someone can tell me where they are.
Maybe I am wrong, but I would see that as intended behavior: the "caret" usually acts on the last segment, meaning that ^14.7.0
is equivalent to >=14.7.0 && < 14.8
, right? Hence the PR to upgrade the requirements to a new range.
I believe ^14.7.0
is equivalent to >=14.7.0 <15.0.0
. https://classic.yarnpkg.com/en/docs/dependency-versions/#toc-caret-ranges
I could be fundamentally misunderstanding what dependabot is supposed to be doing. I thought that it evaluated whether a project could be updated to a newer version of a dependency based on the version constraint. I don't quite understand why it's opening a PR and completely changing the version constraint. Apologies if I've hijacked this issue.
Apologies, I think what I'm observing is not related to this issue and is intended behaviour. See https://dependabot.com/blog/ignoring-major-version-bumps/:
Previously, Dependabot would troll you every time a new 4.x release came out. We liked to call it reminding, but let's be honest. Specifying a version constraint in your package.json wouldn't help either - Dependabot would just bump that constraint for you, too.
Cheers!
You can configure the desired behavior: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates#versioning-strategy by default Dependabot will update to the latest version available. I think lockfile-only
is what you'd want to configure for this
I think this can be resolved by adding the suggested configuration, so I'm going to close this issue out.
We're using dependabot in a javascript project. Today we got a pull request from Dependabot to upgrade a lib to a new major version, while our
package.json
defines the version^3.6.1
, which should mean not to change the most left digit..dependabot/config.yml
:package.json
:Corresponding log from Dependabot:
Is this a bug in Dependabot?