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>
(cherry picked from commit 3758e5b1648a26fd2343db3c804d32a29ae75ff8)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d141fb8b256d86a0a19d0b55084154c8ee15531a..a83fceecdb5dad0391bf0017c9b9c6234a9f5a27 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -270,86 +270,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
 

diff --git a/maint/release-checklist.md b/maint/release-checklist.md
new file mode 100644 (file)
index 0000000..5de8793
--- /dev/null
+++ b/maint/release-checklist.md
@@ -0,0 +1,82 @@
+# dbus release checklist
+
+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