Compare commits

...

2 commits

Author SHA1 Message Date
Yaroslav Halchenko
de0b2cd8ad
Merge 3b11caf218 into 9e62be81b2 2025-03-05 17:03:08 +02:00
Yaroslav Halchenko
3b11caf218 Improve wording and "fix example" (remove 3.13) on testing against pre-releases
3.13 was added in a mass tune up in 0b93645e9f , without
adjusting the wording. With 3.13 listed there too, example does not really make much
sense. So I decided to make it explicit in wording and remove 3.13, so whenever next
refactoring to add 3.14 to be added to every line where 3.13 is -- this would not
even come to attention
2024-12-05 16:10:52 -05:00

View file

@ -613,7 +613,7 @@ The `allow-prereleases` flag defaults to `false`.
If `allow-prereleases` is set to `true`, the action will allow falling back to pre-release versions of Python when a matching GA version of Python is not available.
This allows for example to simplify reuse of `python-version` as an input of nox for pre-releases of Python by not requiring manipulation of the `3.y-dev` specifier.
For CPython, `allow-prereleases` will only have effect for `x.y` version range (e.g. `3.12`).
Let's say that python 3.12 is not generally available, the following workflow will fallback to the most recent pre-release of python 3.12:
Let's say that in the past, when python 3.12 was not yet generally available, the following workflow would have fallback to the most recent pre-release of python 3.12:
```yaml
jobs:
test:
@ -623,7 +623,7 @@ jobs:
fail-fast: false
matrix:
os: [Ubuntu, Windows, macOS]
python_version: ["3.11", "3.12", "3.13"]
python_version: ["3.11", "3.12"]
steps:
- uses: actions/checkout@v4