PEP-101: Improve description of Windows build steps for release (#1710)

This commit is contained in:
Steve Dower 2020-11-10 00:14:14 +00:00 committed by GitHub
parent e374575f20
commit 7a89293d05
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 29 deletions

View File

@ -370,44 +370,36 @@ to perform some manual editing steps.
order to create the release. There are things you can do while you wait
though, so keep reading until you hit the next STOP.
- The WE builds the Windows helpfile, using (in Doc/)::
- The WE generates and publishes the Windows files using the Azure
Pipelines build scripts in ``.azure-pipelines/windows-release/``,
currently set up at https://dev.azure.com/Python/cpython/_build?definitionId=21.
% make.bat htmlhelp (on Windows)
Note that this build requires a separate VM containing the code signing
certificate. This VM is managed by the WE to ensure only official releases
have access to the certificate.
to create suitable input for HTML Help Workshop in build/htmlhelp. HTML
Help Workshop is then fired up on the created python33.hhp file, finally
resulting in an python33.chm file.
The build process runs in multiple stages, with each stage's output being
available as a downloadable artifact. The stages are:
- The WE then generates Windows installer files for each Windows
target architecture (for Python 3.3, this means x86 and AMD64).
- Compile all variants of binaries (32-bit, 64-bit, debug/release),
including running profile-guided optimization.
- The WE has one checkout tree per target architecture, and builds the
pcbuild.sln project for the appropriate architecture.
- Compile the HTML Help file containing the Python documentation
- PC\\icons.mak must have been run with nmake.
- Codesign all the binaries with the PSF's certificate
- The cmd.exe window in which this is run must have Cygwin/bin in its
path (at least for x86).
- Create packages for python.org, nuget.org, the embeddable distro and
the Windows Store
- The cmd.exe window must have MS compiler tools for the target
architecture in its path (VS 2010 for Python 3.3).
- Perform basic verification of the installers
- The WE then edits Tools/msi/config.py (a file only present locally)
to update full_current_version and sets snapshot to false. Currently
for a release config.py looks like::
- Upload packages to python.org and nuget.org, purge download caches and
run a test download.
snapshot=0
full_current_version="3.3.5rc2"
certname="Python Software Foundation
PCBUILD='PCbuild\\amd64'
The last line is only present for the amd64 checkout.
- Now the WE runs msi.py with ActivePython or Python with pywin32.
The WE checksums the files (``*.msi``, ``*.chm``, ``*-pdb.zip``), uploads them to
downloads.nyc1.psf.io together with gpg signature files, and emails you the
location and md5sums.
After the uploads are complete, the WE copies the generated hashes from
the build logs and emails them to the RM. The Windows Store packages are
uploaded manually to https://partner.microsoft.com/dashboard/home by the
WE.
- The ME builds Mac installer packages and uploads them to
downloads.nyc1.psf.io together with gpg signature files.