Add the docker-compose, docker-buildx, and docker-buildkit plugins to the update policy exception list. Only the latest release for each plugin plus the development branch receives security and bug fixes in addition to new features.
Provides supported and maintained versions of these three (3) Docker cli plugins to Fedora users.
Three Docker plugins are provided as Fedora rpms: docker-compose, docker-buildx, and docker-buildkit. The applications in these rpms work with the Docker command line client provided in the docker-cli package (subpackage to moby-engine rpm).
All 3 plugins have a relatively rapid update cycle. Docker-compose for example currently has these versions available: F43 - v2.35.0, F42 - v2.33.1, F41 - v2.30.3, F40 - v1.29.2. Only v2.35.0 is supported leaving all supported Fedora releases with unmaintained versions. There are open CVE bugzilla issues for some of these unsupported versions.
The docker-buildx and docker-buildkit rpms are in similar circumstances with a rarely used caveat from upstream: Once a new feature release is cut, no support is offered for the previous feature release. An exception might be if a security release suddenly appears very soon after a new feature release.
Once a new feature release is cut, no support is offered for the previous feature release. An exception might be if a security release suddenly appears very soon after a new feature release.
It is possible that the oldest, supported Fedora release (e.g. F40 at this time) will not provide a suitable version of the Go language needed to build these plugins. If this condition occurs, an announcement to Fedora developers and user Forums will be made.
Buildkit: https://github.com/moby/buildkit/blob/master/PROJECT.md#release-milestones Buildx: https://github.com/docker/buildx/blob/master/PROJECT.md#types-of-releases Compose: https://github.com/docker/compose?tab=security-ov-file
This is a reasonable permanent exception. +1
Metadata Update from @ngompa: - Issue tagged with: updates policy exception
Other than a v1 -> v2 bump in F40, updating the other branches should be semver compatible and thus already allowed under the updates policy.
So - you're saying this is not needed yet, or at least a permanent one is not needed, and we can just grant a one-off exception for F40? (F40 is going EOL in less than a month, in which case is it even worth updating)
+1 to make a permanent exception. (I think it's fine to make this explicit, even if most of the time the update would be allowed anyway under the generic rules.)
I'm +1 as well
Are those projects actually following SemVer though? If yes, then I agree that those updates from 2.x to 2.y should be fine even without an exception. But in general, I'm fine with +1 to a general exception too ... (and it might be too late for F40 anyway).
Are those projects actually following SemVer though? If yes, then I agree that those updates from 2.x to 2.y should be fine even without an exception. But in general, I'm fine with +1 to a general exception too
Yes, these three projects are more or less following SemVer with frequent increments in the "minor" version. Their record to date are few patch releases before another minor release.
The v1 to v2 change for Docker Compose was comprehensive. V1 was a standalone program written in Python. V2 is deploy as a plugin to docker (also usable by podman) and written in Go. V2 also comes with a V2 compose file format (which is different from the legacy 2.x and 3.x formats supported by Compose V1.
Are those projects actually following SemVer though? If yes, then I agree that those updates from 2.x to 2.y should be fine even without an exception. But in general, I'm fine with +1 to a general exception too Yes, these three projects are more or less following SemVer with frequent increments in the "minor" version. Their record to date are few patch releases before another minor release.
So shouldn't it be okay to perform the updates you want in F41-F42 under the existing Guidelines without an exception?
The update from v1 -> v2 is a complete rewrite. Is that really something we want in F40, especially with it going EOL soon?
I'd be more inclined to get an exception to update moby-engine itself since the version in F40 is quite old and not supported upstream and may have unpatched vulnerabilities.
Both Buildx and Buildkit are version 0.x.x and the semantic versioning standard says:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
So this could potentially result in some churn for the user community and seems to potentially conflict with the Fedora notion of "stable" releases. Given the policies for these products that only the current release is supported, however, seems compelling and I think worth checking in with FESCo.
I am not planning on doing anything for F40 and Compose.
I do have a draft PR to do just that. I have been negligent is submitting the ticket to FESCo.
Ah, I see. So it seems this request makes sense for buildx and buildkit until they have a stable release but not for compose which has already had a stable v2 release for some time.
Since they were all plug-ins as part of the same docker ecosystem I thought it best to be inclusive.
Metadata Update from @fale: - Issue tagged with: meeting
APPROVED (6,0,-0)
Metadata Update from @fale: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @ngompa: - Issue status updated to: Open (was: Closed)
This needs to be documented before closing since this is a permanent exception.
Metadata Update from @ngompa: - Issue tagged with: document it
https://pagure.io/fesco/fesco-docs/pull-request/106
Metadata Update from @zbyszek: - Issue untagged with: meeting
Done.
Metadata Update from @zbyszek: - Issue untagged with: document it - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.