Description

related:

• Create separate go modules for api, client, and daemon #49873
• deconstruct the dockerversion package and move internal #50715

api: include module versions in "Components" response

With the migration to modules, the daemon is built using separate

• the api module; usually this would be matching the maximum API version supported by the daemon, but can be a higher version of the api module, with the daemon configured to support a maximum/minimum version.
• the "v2" module; this module contains the daemon implementation and code used for building the binaries

We want to decouple the daemon binary version from the module versions; after the module transition we can no longer tag the repository using the versions used for the binaries (TODO: link related ticket(s)), but users of the daemon binaries should be able to get information about the code the daemon was built from.

The /version endpoint provides a Components struct that is used to include information about the components running on the daemon side (currently also including information about the versions of containerd, runc and docker-init (tini) that are used). We should extend the information for the "Engine" (daemon) component to include information of the module(s) used to build the binary;

• The tag for the github.com/moby/moby/v2 module
• Consider removing the Git commit field, as it would be the equivalent of the github.com/moby/moby/v2 module
• TBD: the version of the github.com/moby/moby/api module, but this may be redundant as this version is defined in the github.com/moby/moby/v2 module's go.mod

Example of the current output on the command line;

Client: Docker Engine - Community
 Version:           28.4.0
 API version:       1.51
 Go version:        go1.24.7
 Git commit:        d8eb465
 Built:             Wed Sep  3 20:57:20 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.4.0
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.7
  Git commit:       249d679
  Built:            Wed Sep  3 20:57:20 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

And in JSON format;

 "Server": {
    "Platform": {
      "Name": "Docker Engine - Community"
    },
    "Components": [
      {
        "Name": "Engine",
        "Version": "28.4.0",
        "Details": {
          "ApiVersion": "1.51",
          "Arch": "amd64",
          "BuildTime": "Wed Sep  3 20:57:20 2025",
          "Experimental": "false",
          "GitCommit": "249d679",
          "GoVersion": "go1.24.7",
          "KernelVersion": "6.14.0-23-generic",
          "MinAPIVersion": "1.24",
          "Os": "linux"
        }
      },

Questions to be looked into

• Is the module version always available; also when built in non-module mode?
• Is the/a version available when built from a tarbal (not a git clone)?
• Do we need a way to override the version at compile time; similar to what we provide for Git Commit (which is used when built from a tarball)
• Can we use a similar approach as is used for BuildKit?

  moby/daemon/internal/builder-next/worker/mod/mod.go

  Lines 16 to 20 in 8e946ee

  	func Version(name string) (modVersion string) {
  	return moduleVersion(name, readBuildInfo())
  	}
  	func moduleVersion(name string, bi *debug.BuildInfo) (modVersion string) {