Build against pre-releases then stable releases.

[jaraco]

I use this technique in jaraco/skeleton (and derived projects) to reduce the number of commits necessary to adopt a Python version by 50% (by adopting each version during pre-release and then switching to stable once final is released). In actions/setup-python#213, I've reported the issue and I'm hoping that soon, "N.NN" will be sufficient to have the same behavior without having to require adding '-dev' and removing it later.

Feel free to reject if the ugliness outweighs the benefit.

[codecov]

Codecov Report

Merging #472 (bf2d6f9) into main (ad03d53) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #472   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           18        18           
  Lines         1760      1760           
  Branches       213       213           
=========================================
  Hits          1760      1760           

Flag	Coverage Δ
Python_3.10	?
Python_3.11-dev	?
Python_3.8	?
Python_3.9	?

Flags with carried forward coverage won't be shown. Click here to find out more.

[ezio-melotti]

I think this comment could be clearer.
IIUC this syntax is a workaround that will pick the latest available version (which is what we want), and the version could be an alpha, a beta, or a final/stable release.

[jaraco]

I copied this comment verbatim from jaraco/skeleton. I agree, the comment could provide a whole narrative about why it exists, but I try to be concise, to describe as briefly as possible the reason for the syntax, and then link to an issue that provides more context and tracks ultimate resolution.

If you'd like to suggest different wording, I'd be willing to apply that here and in jaraco/skeleton.

[hugovk]

I use this technique in jaraco/skeleton (and derived projects) to reduce the number of commits necessary to adopt a Python version by 50% (by adopting each version during pre-release and then switching to stable once final is released). In actions/setup-python#213, I've reported the issue and I'm hoping that soon, "N.NN" will be sufficient to have the same behavior without having to require adding '-dev' and removing it later.

Feel free to reject if the ugliness outweighs the benefit.

I think it's fine to add 3.11-dev during pre-release, and then change to 3.11 on final release. That's only one extra commit and the config is much easier to understand.

The good news: there's an open PR to fix actions/setup-python#213 that would allow us just to say 3.11 and it will test pre-release or stable, whichever is newest: actions/setup-python#414

[jaraco]

I think it's fine to add 3.11-dev during pre-release, and then change to 3.11 on final release. That's only one extra commit and the config is much easier to understand.

Is it fine? I know for myself, I maintain hundreds of different projects, so each change requires a new commit in each repo, and leaves that repo stale until I get around to making that commit. Honestly, I'd like to get to a place where I can make zero changes to the repo and it will automatically pick up new Python versions, but cutting in half the number of commits required is a real time saver for me.

The good news: there's an open PR to fix actions/setup-python#213 that would allow us just to say 3.11 and it will test pre-release or stable, whichever is newest: actions/setup-python#414

The bad news is that the maintainers are pushing back and insisting that the ugly workaround presented above is preferable. I hope by sharing this current-best-option and linking to the request, it will increase visibility and maybe help motivate a proper fix.

Of course, this project doesn't need to be a part of my advocacy, so feel free to reject.

I acknowledge, this syntax can and should go away if actions/setup-python#414 is merged and released and applied here.

[ezio-melotti]

Maybe something like this? I also expanded the link to make it easier to open.

Suggested change

	# Build on pre-releases until stable, then stable releases.
	# actions/setup-python#213
	# This syntax will select the latest available releases
	# including alpha, then beta, and finally stable releases.
	# See /~https://github.com/actions/setup-python/issues/213

[ezio-melotti]

I acknowledge, this syntax can and should go away if actions/setup-python#414 is merged and released and applied here.

This is now merged and the workaround no-longer needed, so this PR can probably be closed. Note that there is an unrelated and ongoing issue about 3.12 (see #542), but after that is resolved we should be able to just use 3.12 in the workflow.