bump buildkit to 0.11.4 #10772
bump buildkit to 0.11.4 #10772
Conversation
Signed-off-by: Nicolas De Loof <[email protected]>
ndeloof
requested review from
milas,
glours,
laurazard,
a team,
nicksieger,
StefanScherer and
ulyssessouza
and removed request for
a team
|
I think we should use this PR instead to be sure the version of buildkit is align with the one defined in buildx |
| github.com/moby/buildkit v0.11.0-rc3.0.20230609092854-67a08623b95a | ||
| github.com/moby/buildkit v0.11.4 |
There was a problem hiding this comment.
v0.11.0-rc3.0.20230609092854-67a08623b95a. which is actually "v0.12-dev"
The v0.11.0-rc3.0.20230609092854-67a08623b95a pseudo version is based on the last tag that was cut from master (v0.11.0-rc3), which always makes it confusing. (sigh)
But if you look at the commit; moby/buildkit@67a08623b95a, then you'll see it's a commit from master;
There was a problem hiding this comment.
v0.11.4 is older than v0.11.0-rc3
seriously? 😰
There was a problem hiding this comment.
Yeah, go modules tried to be smart and create versions for non-tagged commits, and it does so by;
- taking the commit
- find the last tag in the commit's history (in this case: master branch)
- if the tag cannot be parsed as SemVer, continue with the next one
- once a "SemVer" tag is found, take the tag and increment "Z" (
vX.Y.Z+1) - ...and that's what they use as "pseudo version" prefix
Which, erm, doesn't really work if a project uses release-branches, and the last tag was the pre-release before the release-branch was created.
Related issue
closes https://github.com/docker/compose/security/dependabot/21
(not mandatory) A picture of a cute animal, if possible in relation to what you did