Context
The release pipeline currently invokes .github/workflows/_build.yml once from .github/workflows/release.yml. As a result, it produces a single MSI installer using the python-version input, whose default is currently hard-coded to Python 3.11.
We need to keep a Python 3.11-based installer for Windows 7 SP1 while allowing the regular installer to move to a newer supported Python version. The pipeline should support this generically instead of adding a one-off Win7 build.
Proposed change
Rework the release workflow so that one top-level release orchestration can produce an explicit, hard-coded list of Python-specific MSI variants. The existing per-version build logic should become a reusable stage called once for each configured Python version.
Only the MSI build needs to fan out by Python version. Shared release outputs and publication steps, such as Python distributions, PDF documentation, PyPI publication, checksums, provenance attestations, and creation of the draft GitHub Release, should still run once per tag whenever possible.
All MSI variants must be attached to the same draft GitHub Release. Artifact names and final MSI filenames must include enough information to distinguish the Python or Windows compatibility target and prevent collisions between matrix jobs.
The Windows 7 compatibility DLL must only be copied into builds using Python 3.11 or earlier. The current unconditional step in .github/workflows/_build.yml is:
# Windows 7 SP1 compatibility shim:
# CPython 3.11 needs this Wine-built DLL to run on Windows 7.
Copy-Item resources/api-ms-win-core-path-l1-1-0.dll dist/DataLab/_internal/ -Force
The condition must compare parsed version values, or use an explicit per-matrix-entry compatibility flag, rather than relying on lexicographical string comparison.
Acceptance criteria
- The Python versions used for MSI builds are declared explicitly in the top-level release workflow.
- A release tag produces one MSI installer for every configured Python version.
- Python 3.11 remains configured as the Windows 7 SP1-compatible build.
api-ms-win-core-path-l1-1-0.dll is bundled only when the selected Python version is 3.11 or earlier.
- MSI artifacts and filenames are unique across Python variants and clearly identify their compatibility target.
- A single draft GitHub Release contains all MSI variants together with the shared wheel, source distribution, PDF documentation, and checksum file.
- PyPI publication and other shared publication work are not duplicated for each Python version.
- Build provenance attestations and
SHA256SUMS cover every published MSI variant.
- The release-candidate workflow, if it uses the same build path, follows the same Python-version matrix and DLL inclusion rules.
Context
The release pipeline currently invokes
.github/workflows/_build.ymlonce from.github/workflows/release.yml. As a result, it produces a single MSI installer using thepython-versioninput, whose default is currently hard-coded to Python 3.11.We need to keep a Python 3.11-based installer for Windows 7 SP1 while allowing the regular installer to move to a newer supported Python version. The pipeline should support this generically instead of adding a one-off Win7 build.
Proposed change
Rework the release workflow so that one top-level release orchestration can produce an explicit, hard-coded list of Python-specific MSI variants. The existing per-version build logic should become a reusable stage called once for each configured Python version.
Only the MSI build needs to fan out by Python version. Shared release outputs and publication steps, such as Python distributions, PDF documentation, PyPI publication, checksums, provenance attestations, and creation of the draft GitHub Release, should still run once per tag whenever possible.
All MSI variants must be attached to the same draft GitHub Release. Artifact names and final MSI filenames must include enough information to distinguish the Python or Windows compatibility target and prevent collisions between matrix jobs.
The Windows 7 compatibility DLL must only be copied into builds using Python 3.11 or earlier. The current unconditional step in
.github/workflows/_build.ymlis:The condition must compare parsed version values, or use an explicit per-matrix-entry compatibility flag, rather than relying on lexicographical string comparison.
Acceptance criteria
api-ms-win-core-path-l1-1-0.dllis bundled only when the selected Python version is 3.11 or earlier.SHA256SUMScover every published MSI variant.