Group updates on Semantic Versioning level Beta #7795
Comments
|
I've enabled all the repo's that have requested beta access so far, there were a few cases where I could not make out the repo because an account name was not present or the request was for "all repo's in org x", which is not something we are doing right now, and in that case I'd recommend waiting out until the public beta which should happen shortly if we don't find any showstoppers in this private beta round. Will enable another round tomorrow |
|
risingwavelabs/risingwave#11680
https://doc.rust-lang.org/cargo/reference/semver.html Although it seems this isn't defined in the official SemVer spec. It just mentions
But I think respecting the "y" as major convention is beneficial. |
|
Hmm yeah that's an interesting one @xxchan. It's a bit tricky because it's not in the spec, and doing that means we'll have to make an exception in our code and documentation to clarify this exception for the Rust ecosystem. I can imagine it could also be confusing to folks in the rust community no matter what we do here, on the one hand we're saying Dependabot is grouping these based on SemVer, but on the other hand Rust folks might be used to Rust not following SemVer. Let me think about this a bit! |
I agree that the spec on https://semver.org is less prescriptive (or perhaps even differs) from the Rust semver rules, however, I think the Dependabot implementation is still incorrect for non-Rust usages too? That is, it seems there are three ways Dependabot could handle pre-zero versions:
The Rust semver rules would be (2), and the https://semver.org rules would seem to suggest (3) - but Dependabot is currently implementing (1), which matches neither (and IMO is the worst of all options, since it risks pulling major changes into the grouped PRs -- false positives would be worse than false negatives etc). |
|
@edmorley yes I think there's some merit to what you're saying, there's a case to be made for us to standardize on (3), since SemVer is essentially saying anything below 1 is a free for all. I can imagine this will end up being frustrating for some customers though, because it means there's no way for them to meaningfully group a dependency that is not > 1.0. I appreciate your input, asking for input from folks on my team 👍 Edit: I think what I struggle with mostly right now is that SemVer is not explicitly saying (3), it's saying that before 1.0 it's |
|
Interestingly, I think this (1) is also how our current |
Indeed. BTW, Here are some discussions about the leading zero thing. Excluding
I would recommend have some case studies about how people in different communities, besides Rust, treat the e.g., It seems Although it by default starts at I just personally feel that people either don't use |
|
Does anyone has issue when using the groups ? After merge the config here, i am getting following error logs. |
|
We were reviewing the above and we believe that the root cause for this error is caused in this line: Because the call to And the Tag's name attribute is indeed a String: I believe this could be resolved by calling |
|
Group by |
|
Please could someone take a look at #7305? It makes onboarding existing repos into grouped updates much more painful, since:
|
|
Hi again, thank you for working on this but I am still facing problem regarding group update for dockerfile, it just can't run see logs. In the meanwhile i tested the group update on go dependencies, it seems working correctly. Please help it is currently blocking us. |
|
We're also running into this issue with the documented behaving not matching the implementation: #7939 |
hey @ying-jeanne did you solve this? I'm getting lots of these all across my npm directories. |
|
If I create a group with |
|
Oh, that's not working anyway. I'm seeing the same error as others: |
|
Hi, providing a bit of feedback on this feature: My team want to group our PRs into "major" and "non-major" updates. The "update-types" parameter seems to solve for this however because it tracks the "highest resolvable version" when a dependency has a major and a non-major version increment the non-major group will not offer an update. This is a shame since I may be unable to update to a new major version immediately (or ever), but I would still like to update my dependency to consume any non-breaking improvements. As an example: If my solution depends on a version 1.0.0 and a 1.0.1 and a 2.0.0 exists then the non-major dependabot group will not offer an update to 1.0.1. I'd like to have an option to consume any minor or patch increments via dependabot regardless of whether a major increment exists. Perhaps this could be offered in a future update? Or perhaps I'm missing something! |
I also wanted this feature but realized, grouping major version updates does not make sense for my team (usually), because one major update of a dependency could also be a project on its own (unless it requires a major update of another dep, who knows). Therefore I came to peace with not grouping major updates for now and I'm using this stanca here; I have not noticed it having a similar issue but maybe I didn't check properly: - package-ecosystem: npm
directory: /
schedule:
time: "04:00"
interval: weekly
ignore:
- dependency-name: "*"
update-types:
- version-update:semver-minor
- version-update:semver-patch
- package-ecosystem: npm
directory: /
schedule:
time: "04:00"
interval: weekly
groups:
deps:
patterns:
- '*'
update-types:
- minor
- patch
|
|
@williamfigtree using ignore conditions is the recommended setup for this scenario. It does mean that you won't be aware of any major updates, but we ended up making this trade-off after a lot of deliberation as we figured it would be the least confusing behavior for most of our customers, keeping in line with how Dependabot has historically performed updates. @mfn it doesn't seem like that configuration is valid, as we only allow one entry per ecosystem/directory? 🤔 |
@lorengordon yes. Can you create a separate issue for the error you encountered with an example on how to reproduce, please? Thanks! |
wat 😅 Maybe I didn't notice because there may have been no major versions since I added this, it's a smaller project; minor updates definitely work, I process them weekly. |
|
I have selected only minor and patch updates in my grouping and while it will open a separate PR for major updates it will also get included in the grouped PR, without any mention of it in the description. Have I configured this incorrectly? This is the grouped PR that includes a major Redis update. |
|
Semver grouping is released, if you have any problems with it please file a new issue, thanks! |
Patch updates, per semvar, have a low risk of incompatibility and so I think they can all be grouped together. I was going to add `minor` here too, but for dependencies pre-1.0, minor updates can be breaking. There is a dependabot issue asking for this behavior to change: dependabot/dependabot-core#9647. Also some discussion about this on: dependabot/dependabot-core#7795 Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
Patch updates, per semvar, have a low risk of incompatibility and so I think they can all be grouped together. I was going to add `minor` here too, but for dependencies pre-1.0, minor updates can be breaking. There is a dependabot issue asking for this behavior to change: dependabot/dependabot-core#9647. Also some discussion about this on: dependabot/dependabot-core#7795 Signed-off-by: Jesse Szwedko <jesse.szwedko@datadoghq.com>
As part of our effort to release grouped updates for Dependabot, we're rolling out a new feature in closed beta that will allow you to group by semver level.
What this looks like:
For the above configuration, Dependabot will open a grouped PR for any dependencies where the highest resolvable version is a
patchorminorSemVer update, and any dependencies that will be updated to a newmajorversion will be opened as separate, individual PRs.The
update-typeskey can be combined with other group rules, for these examples I will only specify thegroupssection, assume the rest of the config file is the same as the one listed above:For this configuration, any packages matching the pattern
@angular*where the highest resolvable version isminororpatchwill be grouped together, any package that does not match the pattern or that does not update to aminororpatchversion will be opened as a separate PR. For cases where you do not want updates tomajorversions of@angular*packages, you can specify anignorecondition:If you want grouped PRs for development dependencies that have
patchupdates, you would specify:If you want to join the private beta, please fill out this form and we'll enable the feature.
Any other feedback or thoughts are much appreciated
The text was updated successfully, but these errors were encountered: