Fix dependabot incorrectly downgrading docker versions#5886
Fix dependabot incorrectly downgrading docker versions#5886deivid-rodriguez merged 2 commits intomainfrom
Conversation
mattt
left a comment
mattt
left a comment
There was a problem hiding this comment.
Thanks so much for looking into this, @deivid-rodriguez! I really appreciate your quick turnaround.
I left some thoughts about ways to make this more robust. Please double check me on the Ruby comparable stuff in particular, because I have no idea whether it's valid to say that two values aren't equal but are ordered the same.
mattt
left a comment
mattt
left a comment
There was a problem hiding this comment.
Great work on this, @deivid-rodriguez! As we discussed in https://github.com/dependabot/dependabot-core/pull/5886/files#r995981733, it'd be great to take another look at how UpdateChecker and Version divide up responsibilities for version handling, but I don't think that should be a blocker for this fix. I'm excited to get this fix in front of customers soon 😃
|
Thank you @mattt! I will merge and release this on Monday. |
deivid-rodriguez
force-pushed
the
deivid-rodriguez/docker-downgrades
branch
2 times, most recently
from
32dcd51 to
91d26eb
Compare
When one of the version would would more release segments than other, but the other would have a higher update level than the first, then the latter would sort first. For example, 11.1.0_8 would be consider higher than 11.1.0.1_1. To fix the issue, consider release segments and update level as separate versions, and only use the latter for sorting to resolve ties in the release level.
deivid-rodriguez
force-pushed
the
deivid-rodriguez/docker-downgrades
branch
from
91d26eb to
79646dc
Compare
3 participants
In the edge case of Java versions, which include an extra "update_release" separated by
_, and that can also include a variable number of segments, Dependabot would interpret something like11.0.16_8-jdkas higher than11.0.16.1_1-jdk.This is because up until now Dependabot considers all components equally for sorting, and the 4th component in the first version (8) is higher than the 4th component in the second (1), while previous components are equal.
The correct way to do this is to compare the "release segment" first, in this case, 11.0.16 vs 11.0.16.1, and only if those are equal compare the "update segment".
With that logic in place, things sort as they should.