From 2ec62cf7add318047df7ee5e6c986c25d8b76869 Mon Sep 17 00:00:00 2001 From: Tobias Brox Date: Tue, 12 Dec 2023 21:57:52 +0100 Subject: [PATCH] Attempting to document the procedure of doing releases, to reduce the risk of mistakes in the future --- MANIFEST.in | 6 +++--- RELEASE-HOWTO.md | 26 ++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 3 deletions(-) create mode 100644 RELEASE-HOWTO.md diff --git a/MANIFEST.in b/MANIFEST.in index b38a3ffe..5758534d 100644 --- a/MANIFEST.in +++ b/MANIFEST.in @@ -1,4 +1,4 @@ include COPYING.* -include changelog.0.8.md -include README.md -recursive-include tests * +include *.md +recursive-include tests caldav +exclude tests/conf_private.py diff --git a/RELEASE-HOWTO.md b/RELEASE-HOWTO.md new file mode 100644 index 00000000..1fdf0c97 --- /dev/null +++ b/RELEASE-HOWTO.md @@ -0,0 +1,26 @@ +# HOWTO make a new release [DRAFT] + +## Note + +I have no clue on the proper procedures for doing releases, and I keep on doing clumsy mistakes - hence the need for this document. Anyway, perhaps there are better ways of doing releases? Feel free to shout out (or write up a pull-request). + +## Checklist + +* Go through changes since last release and compare it with the `CHANGELOG.md`. Any change should be logged. +* Run tests towards as many servers as possible + * On breakages, record an issue, check if the previous release also breaks. If so, the breakage is most likely due to server changes. For patch-level releases we don't care about such breakages, for minor-level releases we should try to work around problems + * It's proper to document somewhere (TODO: where? how?) what servers have been tested +* Does any of the changes require documentation to be rewritten? The documentation should ideally be in sync with the code upon release time. +* Look through github pull requests and see if there is anything that ought to be included in the release +* For minor and major releases, look through the github issues, anything urgent there that should be fixed prior to doing a new release? +* Write up some release notes. (I typically keep a short summary of the changes in the CHANGELOG, and use that as the release notes). +* Verify that we're on the right branch - `git checkout master`. (`master` may not always be right - sometimes we may want to use a dedicated branch connected to the release-series, i.e. `v1.3`) +* Change the version number in `caldav/__init__.py`. +* Commit the changes (typically `CHANGELOG.md`, `__init__.py`, documentation): `git commit -am "preparing for releasing v${VERSION}` +* Create a tag: `git tag -as v${VERSION}` - use the release notes in the tag message. +* Make a clone: `git clone caldav/ caldav-release ; cd caldav-release ; git checkout v${VERSION}` +* Run tests (particularly the style check): `pytest` and `tox -e style`. +* Double-verify that the version-number in `__init__.py` is correct: `grep version caldav/__init__.py` +* Push the code to github: `cd ~/caldav ; git push ; git push --tags` +* Some people relies on the github release system for finding releases - go to https://github.com/python-caldav/caldav/releases/new, choose the new tag, copy the version number and the release notes in. +* The most important part - push to pypi: `cd ~/caldav-release ; python setup.py sdist bdist_wheel ; python -m twine upload dist/*`