Versioning schema of SLES BCI and how to get "original" SP container

[oli-arborum]

Hello,
I just discovered the SLES BCIs and am wondering how the versioning works:
E.g., for SP7 the current "latest" is 15.7-5.11.3, the versioning seems to start with 15.7-5.5.2, but there is not 15.7-5.6.x or 15.7-5.7.x.
For SP6 the current "latest" is 15.6.47.26.3 (no "-" in the version number like in SP7) and it goes back to at least 15.6.47.5.1.
So, could you elaborate on the used versioning scheme?

Additionally, I would be interested in using "original" SP containers for reproducible builds. This means, I need the tag or version of, e.g., the SLES SP7 BCI with no updates installed (i.e., as delivered by original SP7 ISO). Is there a common way to find it?

Regards, Oliver

[dirkmueller]

Hi @oli-arborum , thanks for your interest in BCI. Starting with SLES 15 SP7, we changed the versioning scheme from (MAJOR.MINOR.SEQ.SRC.REBUILD to MAJOR.MINOR-SEQ.SRC.REBUILD). The reason for that is that the development, language and application containers (e.g. anything listed on registry.suse.com) were using dashes to separate from the OS version as well, so we made the base containers more alike.

I'm explaining that in more detail below:

• MAJOR: The underlying SLES major version, so for example 12, 15 or 16.
• MINOR: the SP / minor version, so 15.7 refers to SLES 15 SP7. 16.0 Refers to SLES 16 in the initial "0" release. next one will be 16.1 arriving in November 2026.
• SEQ: A sequencing number. it has no semantical meaning other than higher means newer. we use this to avoid conflicts in some cases.
• SRC: The number of source changes to the Dockerfile/Kiwi spec (the container build description). This changes when we for whatever reason do a source modification to the build description or any of its referenced components.
• REBUILD: A counter that is increasing (but not entirely sequentially) on every rebuild without a source change on the build description (kiwi or dockerfile). The typical reason for a rebuild is that one of the embedded binary rpms had a maintenance update and we are reflecting that in a rebuilt container.

with other words the change between 15.6.47.26.3 and 15.6.47.26.4 is a plain rebuild without any source changes (so only binaries exchanged). The change between 15.6.47.23.34 and 15.6.26.1 is that there was one or more source changes to the Dockerfile (up to 3 commits). We are not publishing all the containers on registry.suse.com as there is an elaborate QA process and only those containers that pass are published. so there are holes in the list and those are builds that we discarded prior publishing.

Now you're interested in the original container. that is usually the first container where we change the label "release-stage" from "beta" to "released". we do not distinguish those with a dedicated tag. Also, since you mention it that your use case is reproducible builds, if you use the bci-base container with zypper to install additional packages using the pre-configured BCI repository, you need to be aware that this repository is being updated independently of the base container version. which means it always includes the very latest released state, even if you pinned to a very old container base version. We are currently not guaranteeing or testing that the current BCI repository is working with a pinned old container. While in many cases it might work, you might hit corner cases where there are conflicts or where packages pinned / pre-delivered in the container images would get updated to a newer version in order to satisfy dependencies. Therefore, right now in order to "always get the very same packages" for installation, you would have to snapshot the repository yourself and always build a derived container with that snapshotted repository.

If you're fine with those restrictions I can double check the exact tag that refers to the respective GM builds.

[oli-arborum]

Thanks for your detailed explanations!
Regarding the "original container": How can I find out the version identifier where the "release-stage" label changes to "released"? Seems not to be possible with the "tag" selection box on the registry page.
Regarding the SLES zypper repository used by the BCI (which I would need to snapshot); Is this the same as the "usual" SLES repo?

[dirkmueller]

Thanks for your detailed explanations! Regarding the "original container": How can I find out the version identifier where the "release-stage" label changes to "released"? Seems not to be possible with the "tag" selection box on the registry page.

That is correct. we actually hide containers that are of "beta" stage so for SP7, it would be 15.7-5.5.2 and for SP6 15.6.47.5.1. while you can still find older containers on the registry (like for example 15.6.45.31), we're not actively listing them anymore. these are from pre-release (beta) phase.

Regarding the SLES zypper repository used by the BCI (which I would need to snapshot); Is this the same as the "usual" SLES repo?

The embedded BCI repository is a subset of the usual SLES repository (so like 80%+ but not everything is there). The key difference is that the usual SLES repository provides all the package versions, so you can explicitly install an older version, that is not possible with the embedded BCI repository.

[dirkmueller]

In general we would recommend you to only pin on a major.minor version and if there is really a breaking change, which should be very rare, to reach out to SUSE support..