Option to setup the oldest available Python rather than the latest version when a range of version specified

[XuehaiPan]

Description:
Describe your proposal.

When specifying the python-version with a version range or 3.x, the latest version will be installed.

runs-on: ubuntu-latest
steps:
  - name: Checkout
    uses: actions/checkout@v4

  - name: Set up Python
    uses: actions/setup-python@v5
    with:
      python-version: "3.7 - 3.13"

  - name: Lint
    run: pipx run pre-commit ...

This issue requests an opt-in option to let the action install the oldest major version available on the runner rather than the latest.

- name: Set up Python
  uses: actions/setup-python@v5
  with:
    python-version: "3.7 - 3.13"
    oldest-first: true

Justification:
Justification or a use case for your proposal.

Newer Python may introduce new syntax. The valid code that can run on the latest Python may contain syntax errors in older Python. For example, Python 3.12 supports more powerful f-strings.

$ cat test.py
lines = ['a', 'b', 'c']
string = f'The joined lines are:\n{"\n".join(lines)}'
print(string)

$ python3.12 test.py
The joined lines are:
a
b
c

$ python3.11 test.py
  File "/home/PanXuehai/.../test.py", line 2
    string = f'The joined lines are:\n{"\n".join(lines)}'
                                                         ^
SyntaxError: f-string expression part cannot include a backslash

The linting tool may not complain about the backward incompatible code if the linter runs with the latest Python.

One solution is to pin an old Python in the CI manually. However, the GitHub-hosted runner image may be updated separately with actions/setup-python. Users cannot use:

runs-on: ubuntu-latest
steps:
  - name: Set up Python
    uses: actions/setup-python@v5
    with:
      python-version: "3.7"

Because the CI will break when ubuntu-latest changes from ubuntu-22.04 to ubuntu-24.04.

- The version '3.7' with architecture 'x64' was not found for Ubuntu 24.04.
- The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json

This request reduces the potential CI breakage for the two cases above.

Are you willing to submit a PR?

[gowridurgad]

Hello @XuehaiPan,
Thank you for this feature request. We will investigate it and get back to you as soon as we have some feedback.

[aparnajyothi-y]

Hello @XuehaiPan, Thank you for your suggestion. While we understand the need for compatibility with older versions of Python, we recommend upgrading your CI workflows to use non-EOL Python versions (such as 3.8, 3.9, or 3.10), as EOL (End of Life) versions are not supported after their 6-month EOL date and may introduce security risks and instability in your builds.

By using non-EOL versions, you ensure that your CI workflows are running on versions that are actively maintained and receive security updates. If needed, you can pin your workflows to a specific version to maintain consistency across different environments.

We appreciate your understanding and encourage you to reach out if you have any further questions!

[XuehaiPan]

If needed, you can pin your workflows to a specific version to maintain consistency across different environments.

I want to clarify the context of this feature request.

Developers can always pin and update the runner and Python version in their workflow file. But this needs actively watching the upstream image and the Python release. Once a new release is out or an old release support is removed, their workflow suddenly breaks and shows unrelated failure of the user code in CI. Project maintainers need to patch it immediately, and that requires extra maintenance effort.

A simple scenario of this feature request is a wildcarded Python pin:

- name: Set up Python
  uses: actions/setup-python@v5
  with:
    python-version: "3.x"
    oldest-first: true  # the oldest supported non-EOL version