Release: add helper script for release, and checklist for the process.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

doc/MAKING-RELEASES.md

@@ -0,0 +1,54 @@
+Here's a checklist for the release process.
+
+## Leading Up To The Release
+
+1. Talk to team about whether there are any changes which MUST go in
+   this release which may cause delay.
+2. Create a milestone for the *next* release, and go though issues and PR
+   and mark accordingly.
+3. Ask the most significant contributor who has not already named a
+   release to name the release.  CC previous namers and team.
+
+## Prepering for -rc1
+
+1. Check that CHANGELOG.md covers all signficant changes.
+2. Update the CHANGELOG.md with [Unreleased] changed to -rc1, and add a new
+   footnote.
+3. Create a PR with the above.
+
+## Releasing -rc1
+
+1. Merge the PR above.
+2. Tag it `git pull && git tag -s v<VERSION>rc1 && git push --tags`
+3. Update the /topic on #c-lightning on Freenode.
+4. Prepare draft release notes, and share with team for editing.
+5. Upgrade your personal nodes to the rc1, to help testing.
+
+## Tagging the Release
+
+1. Update the CHANGELOG.md; remove -rc1 in both places, and move the
+   [Unreleased] footnote URL from the previous version to the
+   about-to-be-released version.
+2. Commit that, then `git tag -s v<VERSION>  && git push --tags`.
+3. Run `contrib/build-release.sh` to create the images and `SHA256SUMS`.
+4. Upload the files resulting files the release notes to github and
+   save as a draft.
+   (https://github.com/ElementsProject/lightning/releases/)
+5. Ping the rest of the team to check the SHA256SUMS file and then
+   `gpg -sb --armor SHA256SUMS`.
+6. Append the signatures into a file called `SHA256SUMS.asc`, verify
+   with `gpg --verify SHA256SUMS.asc` and include the file in the draft
+   release.
+
+## Performing the Release
+
+1. Edit the GitHub draft and include the `SHA256SUMS.asc` file.
+2. Publish the release as not a draft.
+3. Update the /topic on #c-lightning on Freenode.
+4. Send a mail to c-lightning and lightning-dev mailing lists, using the
+   same wording as the Release Notes in github.
+
+## Post-release
+
+1. Add a new '[Unreleased]' section the CHANGELOG.md with empty headers.
+2. Look through PRs which were delayed for release and merge them.

tools/build-release.sh

@@ -0,0 +1,55 @@
+#! /bin/sh
+set -e
+
+# When run inside docker (from below), we do build and drop result in /release
+if [ x"$1" = x"--inside-docker" ]; then
+    VER="$2"
+    git clone /src /build
+    cd /build
+    ./configure
+    make -j3
+    make install DESTDIR=/"$VER"
+    tar cvfz /release/clightning-"$VER".tar.gz -- *
+    exit 0
+fi
+
+if [ "$(git status --porcelain -u no)" != "" ]; then
+    echo "Not a clean git directory" >&2
+    exit 1
+fi
+
+VERSION=$(git tag --points-at HEAD)
+if [ "$VERSION" = "" ]; then
+    echo "No tagged version at HEAD?" >&2
+    exit 1
+fi
+
+mkdir -p release
+for platform in Fedora-28-amd64 Ubuntu-16.04-amd64 Ubuntu-16.04-i386; do
+    case $platform in
+	Fedora-28-amd64)
+	    DOCKERFILE=contrib/Dockerfile.builder.fedora
+	    TAG=fedora
+	    ;;
+	Ubuntu-16.04-amd64)
+	    DOCKERFILE=contrib/Dockerfile.builder
+	    TAG=ubuntu-amd64
+	    ;;
+	Ubuntu-16.04-i386)
+	    DOCKERFILE=contrib/Dockerfile.builder.i386
+	    TAG=ubuntu-i386
+	    ;;
+	*)
+	    echo "No Dockerfile for $platform" >&2
+	    exit 1
+    esac
+
+    docker build -f $DOCKERFILE -t $TAG .
+    docker run --rm=true -v "$(pwd)":/src:ro -v "$(pwd)"/release:/release $TAG /src/tools/build-release.sh --inside-docker "$VERSION-$platform"
+    docker run --rm=true -w /build $TAG rm -rf /"$VERSION-$platform" /build
+done
+
+git archive --format=zip -o release/clightning-"$VERSION".zip --prefix=lightning-master/ master
+
+sha256sum release/clightning-"$VERSION"* > release/SHA256SUMS
+gpg -sb --armor -o release/SHA256SUMS.asc-"$(gpgconf --list-options gpg | awk -F: '$1 == "default-key" {print $10}' | tr -d '"')" release/SHA256SUMS