GeezerVison

Because 3.12 is still a release candidate and if tests fail for it then one would always want to know if/how other versions also fail.

Note that a failure of the 3.12 job will still be treated as a failed check and will still cause the workflow to be considered to have failed, which we probably want. Setting continue-on-error for the job just overrides the default matrix fail-fast behavior, so the 3.12 job won't cause other jobs from the matrix to be cancelled if it fails. (Other jobs will still cause cancellation.)

I used a technique based on the one in the GitHub Actions documentation, but modified so all versions can be listed in one place and so the automatically generated job names remain short, as they were before.

This also allows actions/setup-python to install a prerelease for 3.12 only, and no longer for other releases. (This is less important, because only under very strange circumstances would only an old prerelease of a stable release be available to the CI runner. But treating 3.12 specially, as above, allows this to be done too, with no increase in complexity.)

This may or may not be considered worthwhile, given that it should be undone sometime not long after the stable 3.12.0 comes out. However, I think the allow-preleases override to true should be undone at that time, so it seems to me that the burden is much the same either way (and the stakes very low, either way, if it is left in place too long).