fix: set fallback default versions to 3.12 -> 3.14 in ciwh workflow

[sbillinge]

Problem

I only noticed too late that I merged this with the fallback default versions being 3.11 - 3.13 and they should be 3.12 - 3.14 in the cibw workflow

Proposed solution

@stevenhua0320 please could you put in a PR to fix that? I will in the meantime test the release. If it doesn't work, we may have more things to fix and we can fix them at the same time, but in any case removing this technical debt should be done in any case.

[ycexiao]

@sbillinge @stevenhua0320 I'm not sure why the fallback occurs, but I believe I have found the solution.

One thing that made it a little complex is that the fallback can not be reproduced in the local environment. The python_version that _build-python-wheel-extension.yml received is not '["3.11", "3.12", "3.13"]' as extracted from pyproject.toml but "3.13", the latest version. Somehow the upstream fallback to '["3.12", "3.13", "3.14"]' https://github.com/diffpy/diffpy.pdffit2/actions/runs/19832924782/job/56851076893

"3.13" is provided instead of '["3.11", "3.12", "3.13"]' as can be seen in

# `_build-wheel-release-upload.yml`
  get-python-version:
    needs: [check-tag-privilege]
    uses: ./.github/workflows/_get-python-version-latest.yml
    with:
      python_version: ${{ inputs.python_version }}

  build-wheel:
    needs: [get-python-version]
    uses: ./.github/workflows/_build-wheel.yml
    with:
      project: ${{ inputs.project }}
      c_extension: ${{ inputs.c_extension }}
      # Convert from number to string
      python_version: ${{ fromJSON(needs.get-python-version.outputs.python_version) }}

# `_get-python-version-latest.yml`
    outputs:
      python_version:
        description: 'Python version to use'
        value: ${{ jobs.extract-latest.outputs.python_version }}

A temporary fix is here https://github.com/ycexiao/release-scripts/tree/test-workflow/.github/workflows. The matrix run successfully https://github.com/ycexiao/diffpy.pdffit2/actions/runs/19948874804/job/57209604002

If it is what we want, we can discuss the official we want. My current thoughts is:

1. Rename the current python_version as latest_python_version.
2. Add another output python_versions in the job `get-python-version.

Also if we want to rename python_version, someother workflow should also be modified.

[ycexiao]

I checked the merged PR, and found that it falls back to 3.12-3.14 because it was hardcoded previously

So the issue here is that we should not modify the existing python_version but add a new input like matrix_python_versions for it.

[sbillinge]

thanks @ycexiao it is a bit hard for me to see what has happened. Is it building successfully using the fallback or because the python versions are now being passed correctly. I would suggest for now to remove the fallbacks. We can add the fallbacks back if we want, but it may actually be undesirable behavior. If the correct versions are not being passed, we may want it to fail in any case.

TL;DR let's remove the fall-back altogether and make sure that the python version obtained from pyproject.toml is being correctly passed through to this workflow.

[stevenhua0320]

@ycexiao For the fallback version we can now just delete it and I saw your commit that you noticed those inconsistencies in the type of python_version between string and number based on previous definition in the subprocess. We can test whether your edit would still work correctly after deleting the fallback version for now. In terms of compatibility and in case undesireable break, it is safer to define another output to prevent confusion.