|
| 1 | +Maintainer's Guide |
| 2 | +================== |
| 3 | + |
| 4 | +The ``tzdata`` repo is intended to be very low-maintenance and highly |
| 5 | +automated. This document serves as a reference guide for various maintenance |
| 6 | +actions that a maintainer may need to take. End users do not need to be |
| 7 | +concerned with the contents of this document. |
| 8 | + |
| 9 | +Requirements |
| 10 | +------------ |
| 11 | + |
| 12 | +Maintenance scripts are orchestrated using |tox|_ environments to manage the |
| 13 | +requirements of each script. The details of each environment can be found in |
| 14 | +the ``tox.ini`` file in the repository root. |
| 15 | + |
| 16 | +The repository also has pre-commit configured to automatically enforce various |
| 17 | +code formatting rules on commit. To use it, install `pre-commit |
| 18 | +<https://pre-commit.com/>`_ and run ``pre-commit install`` in the repository |
| 19 | +root to install the git commit hooks. |
| 20 | + |
| 21 | +Updating to new tz releases |
| 22 | +--------------------------- |
| 23 | + |
| 24 | +When the ``update`` environment is run, it will automatically detect whether |
| 25 | +the current version of the IANA time zone database in the repository matches |
| 26 | +the latest release available from `iana.org |
| 27 | +<https://www.iana.org/time-zones>`_. If a new release is available, ``tox -e |
| 28 | +update`` will download and install it into the repository. |
| 29 | + |
| 30 | +After running ``tox -e update``, the base version should be set to the current |
| 31 | +version of the upstream database, translated into :pep:`440`. The package |
| 32 | +version will start as a release candidate (``rc0``), and will need to be bumped |
| 33 | +to a full release before the final upload to PyPI. For example, when updating |
| 34 | +from 2019c to 2020a:: |
| 35 | + |
| 36 | + $ tox -e update -- --version=2020a |
| 37 | + ... |
| 38 | + $ git diff VERSION |
| 39 | + -2019.3 |
| 40 | + +2020.1rc0 |
| 41 | + |
| 42 | +Once this is done, commit all the changed or added files and make a pull |
| 43 | +request. |
| 44 | + |
| 45 | +Updating the version |
| 46 | +-------------------- |
| 47 | + |
| 48 | +The canonical location for the version is the ``VERSION`` file in the |
| 49 | +repository root, and it is updated in two ways: |
| 50 | + |
| 51 | +1. The "base version" (e.g. 2020.1) is set by ``tox -e update``. |
| 52 | +2. The additional markers such as pre (release candidate), post and dev are |
| 53 | + managed by ``tox -e bump_version``. |
| 54 | + |
| 55 | +The version follows the scheme:: |
| 56 | + |
| 57 | + YYYY.minor[rcX][.postY][.devZ] |
| 58 | + |
| 59 | +Bumping any component removes all values to its right as well, so for example, |
| 60 | +if the base version were ``20201rc1.post2.dev0``:: |
| 61 | + |
| 62 | + $ tox -e bump -- --dev --dry-run |
| 63 | + ... |
| 64 | + 2020.1rc1.post2.dev0 → 2020.1rc1.post2.dev1 |
| 65 | + |
| 66 | + $ tox -e bump -- --post --dry-run |
| 67 | + ... |
| 68 | + 2020.1rc1.post2.dev0 → 2020.1rc1.post3 |
| 69 | + |
| 70 | + $ tox -e bump -- --rc --dry-run |
| 71 | + ... |
| 72 | + 2020.1rc1.post2.dev0 → 2020.1rc2 |
| 73 | + |
| 74 | +To remove all additional markers and get a simple "release" version, use |
| 75 | +``--release``:: |
| 76 | + |
| 77 | + $ tox -e bump -- --release |
| 78 | + ... |
| 79 | + 2020.1rc1.post2.dev0 → 2020.1 |
| 80 | + |
| 81 | +For more information on how to use ``bump_version``, run ``tox -e bump_version |
| 82 | +-- -help``. |
| 83 | + |
| 84 | +Making a release |
| 85 | +---------------- |
| 86 | + |
| 87 | +Release automation is done via the ``publish.yml`` GitHub Actions workflow, |
| 88 | +which is triggered whenever a new tag is pushed and whenever a new GitHub |
| 89 | +release is made. When a new tag is pushed, the project is built and released to |
| 90 | +`Test PyPI <https://test.pypi.org>`_, and when a GitHub release is made, the |
| 91 | +project is built and released to `PyPI <https://pypi.org>`_. |
| 92 | + |
| 93 | +To make a release: |
| 94 | + |
| 95 | +1. Tag the repository with the current version – you can use the |
| 96 | + ``./tag_release.sh`` script in the repository root to source the version |
| 97 | + automatically from the current ``VERSION`` file. |
| 98 | +2. Wait for the GitHub action to succeed, then check the results on |
| 99 | + https://test.pypi.org/project/tzdata/ . |
| 100 | +3. If everything looks good, go into the GitHub repository's `"releases" tab |
| 101 | + <https://github.com/python/tzdata/releases>`_ and click "Create a new |
| 102 | + release"; type the name of the tag into the box, fill out the remainder of |
| 103 | + the form, and click "Publish". |
| 104 | +4. Check that the release action has succeeded, then check that everything looks |
| 105 | + OK on https://pypi.org/project/tzdata/ . |
| 106 | + |
| 107 | +If there's a problem with the release, use ``tox -e bump -- --post`` to create |
| 108 | +a post release, and if it's sufficiently serious, yank the broken version. |
| 109 | + |
| 110 | +It is recommended to start with a release candidate first, since even Test PyPI |
| 111 | +is immutable and each release burns a version number. |
| 112 | + |
| 113 | +.. Links |
| 114 | +.. |tox| replace:: ``tox`` |
| 115 | +.. _tox: https://tox.readthedocs.io/en/latest/ |
0 commit comments