Move release checklist to its own file

In other projects I've found that having a separate file that only
lists the release steps makes them easier to check.

Signed-off-by: Simon McVittie <smcv@collabora.com>

1 files changed, 1 insertions, 80 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 96413c0b..fb163452 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -274,86 +274,7 @@ This section is not directly relevant to infrequent contributors.
 
 ### Releasing
 
-To make a release of D-Bus, do the following:
-
- - check out a fresh copy from Git
-
- - verify that the libtool versioning/library soname is
-   changed if it needs to be, or not changed if not
-
- - update the file NEWS based on the git history
-
- - verify that the version number of dbus-specification.xml is
-   changed if it needs to be; if changes have been made, update the
-   release date in that file
-
- - update the AUTHORS file with "make update-authors" if necessary
-
- - the version number should have major.minor.micro, even
-   if micro is 0, i.e. "1.0.0" and "1.2.0" not "1.0"/"1.2"; the micro
-   version should be even for releases, and odd for intermediate snapshots
-
- - "make distcheck" (DO NOT just "make dist" - pass the check!)
-
- - if make distcheck fails, fix it.
-
- - once distcheck succeeds, "git commit -a".  This is the version
-   of the tree that corresponds exactly to the released tarball.
-
- - tag the tree with "git tag -s -m 'Released X.Y.Z' dbus-X.Y.Z"
-   where X.Y.Z is the version of the release.  If you can't sign
-   then simply created an unsigned annotated tag:
-   "git tag -a -m 'Released X.Y.Z' dbus-X.Y.Z".
-
- - bump the version number up in configure.ac (so the micro version is odd),
-   and commit it.  Make sure you do this *after* tagging the previous
-   release! The idea is that git has a newer version number
-   than anything released. Similarly, bump the version number of
-   dbus-specification.xml and set the release date to "(not finalized)".
-
- - merge the branch you've released to the chronologically-later
-   branch (usually "master"). You'll probably have to fix a merge
-   conflict in configure.ac (the version number).
-
- - push your changes and the tag to the central repository with
-     git push origin master dbus-X.Y dbus-X.Y.Z
-
- - scp your tarball to freedesktop.org server and copy it to
-   dbus.freedesktop.org:/srv/dbus.freedesktop.org/www/releases/dbus/dbus-X.Y.Z.tar.xz.
-   This should be possible if you're in group "dbus"
-
- - Update the online documentation with `make -C doc maintainer-upload-docs`.
-
- - update the wiki page http://www.freedesktop.org/Software/dbus by
-   adding the new release under the Download heading. Then, cut the
-   link and changelog for the previous that was there.
-
- - post to dbus@lists.freedesktop.org announcing the release.
-
-### Making a ".0" stable release
-
-We create a branch for each stable release. The branch name should be
-dbus-X.Y which is a branch that has releases versioned X.Y.Z;
-changes on a stable branch should be limited to significant bug fixes.
-
-Because we won't make minor changes like keeping up with the latest
-deprecations on a stable branch, stable branches should turn off the
-gcc warning for deprecated declarations (e.g. see commit 4ebb275ab7).
-
-Be extra-careful not to merge master (or any branch based on master) into a
-stable branch.
-
-To branch:
-
-    git branch dbus-X.Y
-
-and upload the branch tag to the server:
-
-    git push origin dbus-X.Y
-
-To develop in this branch:
-
-    git checkout dbus-X.Y
+See maint/release-checklist.md.
 
 ### Code reviews