forked from dateutil/dateutil
-
Notifications
You must be signed in to change notification settings - Fork 1
/
RELEASING
79 lines (63 loc) · 3.46 KB
/
RELEASING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
Release Checklist
-----------------------------------------
[ ] 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:
[ ] Invoke `tox -e news -- --version <NEXT_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.
[ ] Follow the "Releasing" steps below
Optional:
----------
[ ] Check that README.rst is up-to-date.
[ ] Check that the documentation builds correctly (cd docs, make html)
Versioning
----------
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.
Instructions
-----------------------------------------
See the instructions at https://packaging.python.org/en/latest/distributing/
for more details.
Building and Releasing
----------------------
Releasing is automated via the `publish.yml` GitHub Actions workflow. When a
new tag is pushed to the repository, the project is automatically built and
uploaded to Test PyPI. When the publish action is triggered manually (see
https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
for more details), the result is uploaded to PyPI.
To make a release:
1. After having made a PR with all the relevant changes, trigger the "Upload
package" to trigger an upload to Test PyPI. If desired, you can push a
`.dev0` or `.rc0` tag first, so that all uploads will have a prefix for the
*next* version rather than the previous version (e.g. if you are releasing
`3.1.2`, without making a new tag releases will have a version like
`3.1.1+gff8893e.d20220603`; if you push a `3.1.2.dev0` tag first, the version
number will be `3.1.2.dev0`, and subsequent commits will be things like
`3.1.2.dev0+fe9dacc4.d20220603`).
2. Check the Test PyPI page for `python-dateutil` to ensure that the dev release
worked correctly: https://test.pypi.org/project/python-dateutil/
Dev releases may not appear as the default page, so click "Release history"
and navigate to the release you are trying to check. Make sure that the
metadata looks right and in particular that the `Requires` metadata is
present.
4. If the release failed or was unsatisfactory in some way, make the required
changes and got back to step 1. Pushing a new tag is not necessary.
5. When everything looks good, merge the release PR, pull the result to your
local branch and create a new tag with a non-dev version number,
e.g. `3.1.2`. Push this to the repository, wait for the Test PyPI run to
trigger, and ensure that the upload worked.
6. Create a new GitHub release with the new entries from `NEWS` in the
description. This will trigger the workflow to build and release the final
version to PyPI.org. Check https://pypi.org/project/python-dateutil to
ensure that everything worked correctly.
7. Delete any dev tags created during the testing process from your upstream
and local branches.