Support major/minor version tags for Docker images

[beliven-alex-zongaro]

👉 Describe the problem

At the moment, image tags require either:

• the full semantic version (e.g. 5.2.3), or
• no version at all (e.g. latest)

This makes it difficult to safely automate updates. Using latest may unintentionally upgrade across major versions (e.g. v4 → v5), potentially introducing breaking changes without notice.

👥 Problem evidence & reach

This affects any team that:

• uses these images in production
• relies on automated or scheduled pulls
• follows semantic versioning best practices

In CI/CD and infrastructure-as-code workflows, pinning only major (or major.minor) versions is a very common and recommended pattern.

🏆 How to solve this problem

Provide additional Docker tags that follow semantic versioning levels, for example:

• 5 → always latest 5.x.x
• 5.2 → always latest 5.2.x
• 5.2.3 → exact version (already available)

This would allow users to choose the right balance between stability and automatic updates.

Detail 1 – Automation safety

• Avoid accidental major upgrades
• Allow scheduled image updates without manual intervention

Detail 2 – Upgrade control

• Teams can explicitly decide when to move from 5 → 6
• The upgrade becomes an intentional change in configuration

🥰 Describe the "impact" on users?

• Safer production deployments
• Easier automation and maintenance
• Fewer unexpected breaking changes
• Better confidence when using docker pull in scheduled jobs or CI pipelines

Overall, this significantly improves reliability for long-running and production-grade setups.

💯 How do we validate the problem is solved?

• Users can pull images using tags like :5 or :5.2
• Pulling :5 does not upgrade to 6.x
• Documentation clearly explains the tagging strategy
• Positive feedback from users adopting automated update workflows

[jaydrogers]

If I am understanding your message correctly, this is already possible: https://serversideup.net/open-source/docker-php/docs/getting-started/choosing-an-image

[beliven-alex-zongaro]

Hi @jaydrogers,

thanks for the clarification and the link.
From what I see in the documentation, this explains how to pin the PHP version (e.g. 8.4, 8.5), but my concern is about the ServerSideUp image version itself, referenced as {{github-release-version}}.

Using tags like 8.4-fpm-nginx still tracks the latest image release, which means it can cross image major versions (for example v4 → v5) without changing the tag.

What we’re looking for is the possibility to pin image major/minor GitHub versions, for example:

• serversideup/php:8.4-fpm-nginx-v4 → automatically updates to the latest v4.x.x
• serversideup/php:8.4-fpm-nginx-v4.2 → automatically updates to the latest v4.2.x
• serversideup/php:8.4-fpm-nginx-v4.2.1 → exact version (already available)

Let me know if I’m missing something.