How are the Docker image tags (latest vs 7.x) intended to be used?

[SolunaCG]

Hi,

I'm a bit confused about the Docker image tagging and would like to understand the intended upgrade path.

My compose file uses:

image: opencloudeu/opencloud:latest

After running docker compose pull and recreating the container, I'm on:

Version: 4.0.8
Compiled: 2026-06-25

The image itself was also built on June 25, so I'm confident I'm using the current latest image.

However, I also noticed that GitHub already has a 7.2.0 Production Release.

So I'm wondering:

• Is latest intentionally staying on the 4.x release line?
• Or is it expected that latest will eventually move to 7.x?
• If users want automatic updates within the recommended production release, should they use :latest, :7, or something else?

I expected :latest to track the newest production release. If the recommended approach is to pin the major version (e.g. :7), is that the intended upgrade strategy for Docker deployments?

I'm just trying to understand the recommended way to keep a Docker deployment up to date over time.

Thanks!

[micbar]

Ah, bad luck.

Sorry for the inconvenience.

We published the 4.0.8 after the 7.2.0 because that is a bugfix for the stable 4 branch.

Now the stable 4 branch switched back the latest tag to 4.0.8. That is an error on our side.

Other than that, i do not see how we should avoid that in the future, other than creating a "latest-4" pseudo tag or something like that.

The latest pseudo tag is one of the worst docker inventions if you ask me.

One could make its life easier by choosing the desired stable branch.

Use 4.0 as a tag for the stable 4 branch.

Then you get all patch releases on docker compose pull

[SolunaCG]

@micbar Thanks, that explains why latest currently points to 4.0.8.

Just to make sure I understand the recommended upgrade path:

If I switch to :4.0, I'll receive all future 4.x patch releases automatically.

But when the next major stable branch (e.g. 8.x) is released, is the expectation that I manually change the image tag from :7 to :8?

In other words, are major version upgrades intentionally a manual step for Docker deployments?

[micbar]

In other words, are major version upgrades intentionally a manual step for Docker deployments?

Correct. Major versions indicate breaking changes and need manual interaction.

[SolunaCG]

Thanks for the clarification!

That makes sense now. I was mainly trying to understand the intended long-term upgrade strategy for Docker deployments, and your explanation answered that.

I appreciate the quick responses!