From b70650f379df1ecfb5aa33cf5260d96ae588777c Mon Sep 17 00:00:00 2001 From: Paul Ganssle Date: Sat, 2 Nov 2019 17:05:48 -0400 Subject: [PATCH] Update RELEASING documentation --- RELEASING | 91 +++++++++++++++++++------------------------------------ 1 file changed, 31 insertions(+), 60 deletions(-) diff --git a/RELEASING b/RELEASING index dcc027c84..a03788a75 100644 --- a/RELEASING +++ b/RELEASING @@ -1,23 +1,20 @@ Release Checklist ----------------------------------------- -[ ] Update __version__ string -[ ] Update classifiers in setup.py to include the latest supported Python +[ ] Update classifiers in setup.cfg to include the latest supported Python versions. [ ] Update the metadata in zonefile_metadata.json to include the latest tzdata release from https://www.iana.org/time-zones. [ ] If necessary, update the tzdata mirror at https://github.com/dateutil/tzdata -[ ] Update NEWS with list of changes, giving credit to contributors. -[ ] Build the source distribution as, at a minimum, .tar.gz and .zip -[ ] Verify that the source distribution contains all necessary components. -[ ] Build the binary distribution as a wheel -[ ] Verify that the binary distribution can be installed and works. -[ ] Generate MD5 hashes for the source and binary distributions -[ ] Sign the source and binary distributions with a GPG key (if not the one - that made the release, then one signed by the one that made the last - release) +[ ] Update NEWS with list of changes: + [ ] Invoke `tox -e towncrier -- --version ` + [ ] Make sure that only `template.rst` remains in changelog.d/ + [ ] Manually clean up the new NEWS file. + [ ] Replace entries in the "Misc" section that are not likely to be + interesting to anyone consuming the package (e.g. changes to CI) with + a reference to the Github PR. [ ] Commit the changes in git and make a pull request. [ ] Accept the pull request and tag the repository with the release number. -[ ] Add the contents of the NEWS file to the github release notes for the +[ ] Add the contents of the NEWS file to the Github release notes for the release. [ ] Upload the source and binary distributions along with hashes and signatures to pypi. @@ -36,60 +33,34 @@ for more details. Versioning ---------- -Try and keep to a semantic versioning scheme (http://semver.org/). +Try and keep to a semantic versioning scheme (http://semver.org/). The versions +are managed with setuptools_scm, so to update the version, simply tag the +relevant commit with the new version number. -Source releases ----------- -Release the sources with, at a minimum, .tar.gz and .zip. Make sure you have a -relatively recent version of setuptools when making the source distribution, as -earlier version will not include the tests. Other formats are -optional. They can be generated using: - - python setup.py sdist --formats=zip,gztar - -To verify that a source release is correct, inspect it using whatever archive -utility you have and make sure it contains all the modules and the tests. Also -make sure that the zoneinfo file is included in the You -may also want to generate a new clean virtualenv and run the tests from the -source distribution (python setup.py test). - - -Binary releases ----------- -It should always be possible to generate a universal wheel binary distribution -for each release. Generally we do not generate .egg files. In order to generate -a wheel, you need the wheel package (https://wheel.readthedocs.io/en/latest/) -installed, which can be installed with: - - pip install wheel - -Once this is done, generate the wheel with: - - python setup.py bdist_wheel - - -Signing and generate checksums ----------- -Since all the outputs are generated in the dist/ directory, can generate all the -md5 checksums at once from the base directory by executing: - - md5sum dist/* - -Save these for when uploading the files. Following this, go into the dist -directory and sign each of the results with the relevant key: +Building and Releasing +---------------------- +Building and releasing can be done using the `release.py` script, which +automates building, signing and uploading. Since it uses GPG for signing and +for decrypting a stored token, it requires that `gpg` be installed on your +system. Because it has python dependencies, the best way to use the +`release.py` script is to invoke it using `tox`. To build the source and binary +distributions, use: - gpg --armor --output .asc --detach-sig + tox -e build -To automate this for all files, you can use the following command: +This will build and sign the distributions and put them in `dist/`. Once that +is done, you can release them with: - for f in dist/*; do gpg --armor --output $f.asc --detach-sig $f; done + tox -e release -Save these .asc files for when uploading to pypi. Before uploading them, verify -that they are valid signatures: +If you have the token stored in your `~/.pypirc` file. If you have stored the +relevant token in an encrypted file, use the `--passfile` argument: - gpg --verify .asc + tox -e release -- --passfile .token.gpg -To do this in bulk, you can use the command: +The `release` command defaults to uploading to test.pypi.org. To upload to +pypi.org, use the `--release` flag, so putting it all together, we have: - for f in $(find ./dist -type f | grep -v '.asc$'); do gpg --verify $f.asc $f; done + tox -e build + tox -e release -- --passfile .token.gpg --release