@@ -118,9 +118,6 @@ The project provides several ``make`` targets to help with development:
118118 run linting, type checking, and tests. This is the recommended command to run
119119 before submitting a pull request.
120120
121- * ``make coverage `` - Run tests with coverage reporting and open the HTML report
122- in your browser.
123-
124121For a full list of available commands, run ``make help ``.
125122
1261237. Commit your changes and push your branch to GitHub::
@@ -151,16 +148,76 @@ To run a subset of tests::
151148
152149$ pytest tests/test_multibase.py
153150
154-
155- Deploying
151+ Releasing
156152---------
157153
158- A reminder for the maintainers on how to deploy.
159- Make sure all your changes are committed (including an entry in HISTORY.rst).
160- Then run::
154+ Releases are typically done from the ``master `` branch, except when releasing a beta (in
155+ which case the beta is released from ``master ``, and the previous stable branch is
156+ released from said branch).
157+
158+ Final test before each release
159+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
160+
161+ Before releasing a new version, build and test the package that will be released:
162+
163+ .. code :: sh
164+
165+ git checkout master && git pull
166+ make package-test
167+
168+ This will build the package and install it in a temporary virtual environment. Follow
169+ the instructions to activate the venv and test whatever you think is important.
170+
171+ You can also preview the release notes:
172+
173+ .. code :: sh
174+
175+ towncrier --draft
176+
177+ Build the release notes
178+ ~~~~~~~~~~~~~~~~~~~~~~~
179+
180+ Before bumping the version number, build the release notes. You must include the part of
181+ the version to bump (see below), which changes how the version number will show in the
182+ release notes.
183+
184+ .. code :: sh
185+
186+ make notes bump=$$ VERSION_PART_TO_BUMP$$
187+
188+ If there are any errors, be sure to re-run make notes until it works.
189+
190+ Push the release to github & pypi
191+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
192+
193+ After confirming that the release package looks okay, release a new version:
194+
195+ .. code :: sh
196+
197+ make release bump=$$ VERSION_PART_TO_BUMP$$
198+
199+ This command will:
200+
201+ - Bump the version number as specified wherever it appears in the repo.
202+ - Create a git commit and tag for the new version.
203+ - Build the package.
204+ - Push the commit and tag to github.
205+ - Push the new package files to pypi.
206+
207+ Which version part to bump
208+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
209+
210+ ``$$VERSION_PART_TO_BUMP$$ `` must be one of: ``major ``, ``minor ``, ``patch ``, ``stage ``,
211+ or ``devnum ``.
212+
213+ The version format for this repo is ``{major}.{minor}.{patch} `` for stable, and
214+ ``{major}.{minor}.{patch}-{stage}.{devnum} `` for unstable (``stage `` can be alpha or
215+ beta).
216+
217+ If you are in a beta version, ``make release bump=stage `` will switch to a stable.
161218
162- $ bump-my-version bump patch # possible: major / minor / patch
163- $ git push
164- $ git push --tags
219+ To issue an unstable version when the current version is stable, specify the new version
220+ explicitly, like ``make release bump="--new-version 4.0.0-alpha.1" ``
165221
166- GitHub Actions will then deploy to PyPI if tests pass.
222+ You can see what the result of bumping any particular version part would be with
223+ ``bump-my-version show-bump ``
0 commit comments