Proposal: Adding Support for Alternative Image Tags in Docker Compose

[yaroslavputria]

Description

Objective:
The goal of this proposal is to enhance Docker Compose by introducing support for specifying alternative image tags for services. This feature will provide users with flexibility in specifying multiple image tags for a service, allowing Docker Compose to attempt pulling the image using alternative tags if the primary tag is not found.

Background:
Currently, Docker Compose only supports specifying a single image tag for each service. If the specified tag is not found in the registry, Docker Compose fails to pull the image. This limitation can be problematic for users who rely on specific tags for their services and want to provide fallback options in case the primary tag is unavailable.

Proposal:
We propose extending the Docker Compose syntax to allow specifying multiple alternative image tags for a service. The syntax will be similar to the following:

version: '3.8'

services:
  myservice:
    image: 
      - myrepo/myimage:tag1
      - myrepo/myimage:tag2
      - myrepo/myimage:tag3

In this example, Docker Compose will attempt to pull the image myrepo/myimage with the tags tag1, tag2, and tag3, in that order. If tag1 is not found, it will try tag2, and so on.

Implementation Details:

1. Modify the Docker Compose parser to recognize and handle lists of alternative image tags under the image key in service definitions.
2. Update the image pulling logic to attempt pulling images using each tag in the specified order until a match is found or all tags have been exhausted.
3. Provide appropriate error handling and logging to inform users if none of the specified tags are found in the registry.

Benefits:

1. Increased Flexibility: Users can specify multiple image tags for services, providing flexibility in handling image versions and dependencies.
2. Improved Reliability: Docker Compose will attempt to pull images using alternative tags if the primary tag is not available, reducing deployment failures due to tag mismatches.
3. Enhanced Compatibility: Existing Docker Compose files can be easily updated to take advantage of the new syntax without breaking compatibility with older versions.

[ndeloof]

I hardly imagine a scenario this would be of any benefit. Do you have any real-world example this could be useful?