Improve wording and "fix example" (remove 3.13) on testing against pre-release
Description:
3.13 was added in a mass tune up in 0b93645e9fea7318ecaed2b359559ac225c90a2b , 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
Check list:
- [ ] Mark if documentation changes are required.
- [ ] Mark if tests were added or updated to cover the changes.
Hi @yarikoptic, thanks for improving the documentation! Since Python 3.14 is now the current pre-release, could you please update both the explanatory paragraph and the matrix example to use "3.14" as the pre-release version instead of 3.12. This will make the example more relevant and accurately demonstrate how allow-prereleases works with an actual pre-release, rather than referencing 3.12, which is already generally available.
Since here I am not adding a new documentation but rather providing minor tune up to already existing wording, which was potentially added when allow-prereleases was added, IMHO would be best to keep example as is. Switching to 3.14 would invalidate added "in the past" and would then require such a PR later to make it again factually correct.
Hi @yarikoptic, To keep the original wording intact, it is suggested to only update the version number from 3.12 to 3.14 in the paragraph, like this:
Let’s say that Python 3.14 is not generally available, the following workflow will fallback to the most recent pre-release of Python 3.14.
And in the matrix, update the version list to:
python_version: ["3.14"]
This way, the example provides a concrete and current reference for configuring workflows with a real pre-release version, making it more practical and helpful for users.