Image ghcr.io/eclipse-sumo/sumo:v1_23_1 ships SUMO 1.23.0, not the 1.23.1 hotfix

[jf972178]

Summary

The container image tagged v1_23_1 contains a sumo binary that reports Version 1.23.0.

Since 1.23.1 was published as a hotfix ("Due to some issues with quality control and conference timing, we are releasing SUMO version 1.23.1 as a hotfix"), anyone pinning v1_23_1 for reproducibility is silently running the pre-hotfix build.

Reproduction

$ docker buildx imagetools inspect ghcr.io/eclipse-sumo/sumo:v1_23_1
MediaType: application/vnd.docker.distribution.manifest.v2+json
Digest:    sha256:9b555a5dfdb2de548b77b4f624855cf9e25fe5b9ec009b6b579e547f23d83d37

$ docker run --rm ghcr.io/eclipse-sumo/sumo:v1_23_1 sumo --version
Eclipse SUMO sumo Version 1.23.0
 Build features: Linux-6.8.0-56-generic x86_64 GNU 10.2.1 Release FMI Proj GUI Intl SWIG Eigen GL2PS

$ docker run --rm ghcr.io/eclipse-sumo/sumo:v1_23_1 which sumo
/usr/local/bin/sumo

Environment: Docker Desktop 4.47.0, engine 28.4.0, linux/amd64. Pulled by digest, all 7 layers complete.

Corroborating timeline

Fact	Value
Binary self-reported version	1.23.0
GHCR publication of image v1_23_1	2025-05-07 18:57:55 UTC
Eclipse release date of SUMO 1.23.1	2025-05-08

The image appears to have been built and pushed the day before the release it is named after, which is consistent with the version string.

Questions

1. Can you confirm the image tagged v1_23_1 does not contain the 1.23.1 hotfix?
2. Is this expected behaviour of the release pipeline, or a one-off for this release?
3. Is the same mismatch present on other vX_Y_Z tags? We need to know whether pinning any version tag is safe, or whether sumo --version must be verified at runtime for every deployment.
4. Will v1_23_1 be rebuilt and republished? If so the digest will change, so could you announce the new digest here?
5. If it will not be rebuilt, which tag and digest do you recommend for consumers who need the 1.23.1 hotfix?

Two documentation points

• The sumo executable is at /usr/local/bin/sumo, not /usr/bin/sumo as one would infer from CMAKE_INSTALL_PREFIX in build_config/docker/Dockerfile.ubuntu.git.
• The image is linux/amd64 only (no platforms: key on docker/build-push-action in .github/workflows/docker.yml). Is linux/arm64 planned? The supported platform list is not stated in the docs.

Context

We are qualifying this image for a reproducible, auditable simulation runtime, where the mapping between artifact reference and software version has to hold. Happy to provide further diagnostics.

[behrisch]

Thanks for reporting! It seems multiple docker images (between 1.22 and 1.26) received the wrong tag. What I did now is to add a correct pep440 compliant tag (e.g. 1.23.0 instead of v1_23_0) to all the containers I checked. I kept the original tag because I did not want to break existing workflows. Some additional stuff:

• The v1_26_0 seems to be broken (wrong parquet installed) see Docker container not working, sumo: error while loading shared libraries: libparquet.so.2300: cannot open shared object file: No such file or directory #18005
• We need to check what the actual difference is between v1_22_0 and v1_23_0.
• We need to add documentation about this issue on the docker page
• Maybe we can add another tag like v1_23_0_wrong or similar to make it clear

[behrisch]

Concerning the docs: For newer docker images sumo is in /usr/bin so the docs are correct because they always refer to the current HEAD.
Concerning arm, yes I think we can add this