Unify RELEASING.rst and RELEASE_PROCESS.md

Update RELEASING.rst with the setuptools-scm tag-based release
process and delete RELEASE_PROCESS.md.

Author: graingert

MANIFEST.in

@@ -1,5 +1,4 @@
 exclude .gitignore
-exclude RELEASE_PROCESS.md
 exclude make_changelog.py
 exclude check_changelog.py
 exclude DEVELOPER.rst

RELEASE_PROCESS.md

@@ -2,17 +2,22 @@
 Releasing unittest2pytest
 =========================
 
-This document describes the steps to make a new ``unittest2pytest`` release.
+``unittest2pytest`` uses `setuptools-scm`_ for version management.
+Versions are derived automatically from git tags.
+
+.. _setuptools-scm: https://github.com/pypa/setuptools-scm
+
 
 Version
 -------
 
-``main`` should always be green and a potential release candidate. ``unittest2pytest`` follows
-semantic versioning, so given that the current version is ``X.Y.Z``, to find the next version number
-one needs to look at the ``CHANGELOG.rst`` file:
+``main`` should always be green and a potential release candidate.
+``unittest2pytest`` follows semantic versioning, so given that the
+current version is ``X.Y.Z``, to find the next version number one
+needs to look at the ``CHANGELOG.rst`` file:
 
-- If there any new feature, then we must make a new **minor** release: next
-  release will be ``X.Y+1.0``.
+- If there any new feature, then we must make a new **minor** release:
+  next release will be ``X.Y+1.0``.
 
 - Otherwise it is just a **bug fix** release: ``X.Y.Z+1``.
 
@@ -22,20 +27,46 @@ Steps
 
 To publish a new release ``X.Y.Z``, the steps are as follows:
 
-#. Create a new branch named ``release-X.Y.Z`` from the latest ``main``.
+#. Update ``CHANGELOG.rst``:
+
+   .. code-block:: console
 
-#. Update the version in ``unittest2pytest/__init__.py``.
+        python make_changelog.py X.Y.Z
 
-#. Update the ``CHANGELOG.rst`` file with the new release information.
+   This replaces the ``UNRELEASED`` section with a dated ``X.Y.Z``
+   section.  Review the result and add any missing entries before
+   committing.
+
+#. Commit and push:
+
+   .. code-block:: console
 
-#. Commit and push the branch to ``upstream`` and open a PR.
+        git commit -am "Prepare release X.Y.Z"
+        git push origin main
 
-#. Once the PR is **green** and **approved**, start the ``deploy`` workflow:
+#. Tag and push:
 
    .. code-block:: console
 
-        gh workflow run deploy.yml -R pytest-dev/unittest2pytest --ref release-VERSION --field version=VERSION
+        git tag -s vX.Y.Z -m "unittest2pytest X.Y.Z"
+        git push origin vX.Y.Z
+
+   Pushing the tag triggers the CI workflow, which builds, tests,
+   publishes to PyPI, and creates a GitHub release.
+
+#. Start the next development cycle:
+
+   .. code-block:: console
+
+        python make_changelog.py UNRELEASED
+        git commit -am "Start next development cycle"
+        git push origin main
+
 
-   The PR will be automatically merged.
+How versioning works
+--------------------
 
-#. Update the version in ``unittest2pytest/__init__.py`` and ``CHANGELOG.rst`` for the next release (usually use "minor+1" with the ``.dev0`` suffix).
+- Tagged commits (e.g. ``v0.6``) produce version ``0.6``.
+- Commits after a tag produce dev versions like ``0.7.dev3+gabcdef``.
+- The version is written to ``unittest2pytest/_version.py`` at build
+  time.  This file is git-ignored and should not be committed.