[RFE] Add ubuntu-earliest, windows-earliest, macos-earliest

[ceztko]

Tool name

N/A

Tool license

N/A

Add or update?

• Add
• Update

Desired version

N/A

Approximate size

No response

Brief description of tool

To maximize compatibility, I prefer to not test on latest operating systems so I always track the oldest available image for running in github action. I'd like also not being bothered when a image is being deleted, so I suggest adding the following links:

• ubuntu-earliest -> ubuntu-22.04
• windows-earliest -> windows-2019
• macos-earliest -> macos-13

In few days windows-2019 will be removed: as soon as it happens windows-earliest would then automatically switch to windows-2022.

URL for tool's homepage

No response

Provide a basic test case to validate the tool's functionality.

Platforms where you need the tool

• Azure DevOps
• GitHub Actions

Runner images where you need the tool

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Can this tool be installed during the build?

Tool installation time in runtime

No response

Are you willing to submit a PR?

No response

[hemanthmanga]

Hi @ceztko, Due to our maintenance and support policies, we are unable to fulfill this request at this time. We will now close this issue. Thank you for your understanding.

[ceztko]

Thanks for the response. May I ask for a comment on the merits of the request? I'm curious whether the idea itself is considered valid/useful. If this isn’t the right venue, is there a better place to discuss it?

[erik-bershel]

TLDR: The idea itself is useful and not new, but in the current circumstances it has not been accepted for implementation due to pitfalls and internal blockers.

The location is correct. There are many doubts, at least:

• 1. Unfortunately, "automatic" switching is currently impossible and this kind of maintenance will require a noticeable amount of human effort.

• 2.1. Maintaining a zoo of additional labels is a rather controversial idea, since they will not solve the problem that the community is trying to solve in this way - ultimately, the goal is to ensure predictability and stability, which cannot be ensured in this way due to the very architecture of the product. When switching labels, users will encounter exactly the same set of problems, namely the difference between the content of images (which means the absence of the -stable tag).

• 2.2. The practical meaning of using labels like -oldest -earliest and so on is also controversial for the current images support model - these labels will not bring any predictability, the only problem they will solve is the lack of need to change the workflow that used the deprecated image. Unfortunately, the need to move to a new image almost always means the need to make changes to the workflow (different versions of runtime tools and more).

• 3. The solution could be to use a truly stable image that will change in a predictable and transparent manner, within a reasonable time frame (long notice period, only security patches, community and usage driven model of default tools updates), which we cannot currently provide within the scope of this product, but we keep the task as such in mind and periodically reanalyze it.