dateutil

1
Release Checklist
2
-----------------------------------------
3
[ ] Update classifiers in setup.cfg to include the latest supported Python
4
    versions.
5
[ ] Update the metadata in zonefile_metadata.json to include the latest tzdata
6
    release from https://www.iana.org/time-zones.
7
[ ] If necessary, update the tzdata mirror at https://github.com/dateutil/tzdata
8
[ ] Update NEWS with list of changes:
9
    [ ] Invoke `tox -e news -- --version <NEXT_VERSION>`
10
    [ ] Make sure that only `template.rst` remains in changelog.d/
11
    [ ] Manually clean up the new NEWS file.
12
    [ ] Replace entries in the "Misc" section that are not likely to be
13
        interesting to anyone consuming the package (e.g. changes to CI) with
14
        a reference to the Github PR.
15
[ ] Commit the changes in git and make a pull request.
16
[ ] Follow the "Releasing" steps below
17

18

19
Optional:
20
----------
21
[ ] Check that README.rst is up-to-date.
22
[ ] Check that the documentation builds correctly (cd docs, make html)
23

24

25
Versioning
26
----------
27
Try and keep to a semantic versioning scheme (http://semver.org/). The versions
28
are managed with `setuptools_scm`, so to update the version, simply tag the
29
relevant commit with the new version number.
30

31

32
Instructions
33
-----------------------------------------
34
See the instructions at https://packaging.python.org/en/latest/distributing/
35
for more details.
36

37

38
Building and Releasing
39
----------------------
40
Releasing is automated via the `publish.yml` GitHub Actions workflow. When a
41
new tag is pushed to the repository, the project is automatically built and
42
uploaded to Test PyPI. When the publish action is triggered manually (see
43
https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
44
for more details), the result is uploaded to PyPI.
45

46
To make a release:
47

48
1. After having made a PR with all the relevant changes, trigger the "Upload
49
   package" to trigger an upload to Test PyPI. If desired, you can push a
50
   `.dev0` or `.rc0` tag first, so that all uploads will have a prefix for the
51
   *next* version rather than the previous version (e.g. if you are releasing
52
   `3.1.2`, without making a new tag releases will have a version like
53
   `3.1.1+gff8893e.d20220603`; if you push a `3.1.2.dev0` tag first, the version
54
   number will be `3.1.2.dev0`, and subsequent commits will be things like
55
   `3.1.2.dev0+fe9dacc4.d20220603`).
56

57
2. Check the Test PyPI page for `python-dateutil` to ensure that the dev release
58
   worked correctly: https://test.pypi.org/project/python-dateutil/
59

60
   Dev releases may not appear as the default page, so click "Release history"
61
   and navigate to the release you are trying to check. Make sure that the
62
   metadata looks right and in particular that the `Requires` metadata is
63
   present.
64

65
4. If the release failed or was unsatisfactory in some way, make the required
66
   changes and got back to step 1. Pushing a new tag is not necessary.
67

68
5. When everything looks good, merge the release PR, pull the result to your
69
   local branch and create a new tag with a non-dev version number,
70
   e.g. `3.1.2`. Push this to the repository, wait for the Test PyPI run to
71
   trigger, and ensure that the upload worked.
72

73
6. Create a new GitHub release with the new entries from `NEWS` in the
74
   description. This will trigger the workflow to build and release the final
75
   version to PyPI.org. Check https://pypi.org/project/python-dateutil to
76
   ensure that everything worked correctly.
77

78
7. Delete any dev tags created during the testing process from your upstream
79
   and local branches.
80