Make rc announcement mandatory

Last month, when people upgraded their K8S clusters to use Engine 1.13, networking broke for them
because the default forwarding policy changed to `DROP` to increase the security and prevent some
specific network attacks. After a [long discussion on Twitter](https://twitter.com/jbeda/status/826969113801093121)
we realized that while the 1.13-rc releases had been out for months, they hadn't received as much
testing as we wanted because they hadn't been announced through all available channels.

This is a proposal to alter the release process to make sure that release candidate versions are
announced as widely as possible.

Signed-off-by: Jerome Petazzoni <jerome.petazzoni@gmail.com>

project/RELEASE-CHECKLIST.md

@@ -312,16 +312,17 @@ echo "Linux 64bit tgz: https://test.docker.com/builds/Linux/x86_64/docker-${VERS
 echo "Windows 64bit client binary: https://test.docker.com/builds/Windows/x86_64/docker-${VERSION#v}.exe"
 echo "Windows 32bit client binary: https://test.docker.com/builds/Windows/i386/docker-${VERSION#v}.exe"
 ```
+### 13. Announce the release candidate
 
-We recommend announcing the release candidate on:
+The release candidate should be announced on:
 
 - IRC on #docker, #docker-dev, #docker-maintainers
 - In a comment on the pull request to notify subscribed people on GitHub
 - The [docker-dev](https://groups.google.com/forum/#!forum/docker-dev) group
 - The [docker-maintainers](https://groups.google.com/a/dockerproject.org/forum/#!forum/maintainers) group
-- Any social media that can bring some attention to the release candidate
+- (Optional) Any social media that can bring some attention to the release candidate
 
-### 13. Iterate on successive release candidates
+### 14. Iterate on successive release candidates
 
 Spend several days along with the community explicitly investing time and
 resources to try and break Docker in every possible way, documenting any
@@ -368,10 +369,10 @@ git commit --amend
 git push -f $GITHUBUSER bump_$VERSION
 ```
 
-Repeat step 6 to tag the code, publish new binaries, announce availability, and
+Repeat steps 6 to 14 to tag the code, publish new binaries, announce availability, and
 get help testing.
 
-### 14. Finalize the bump branch
+### 15. Finalize the bump branch
 
 When you're happy with the quality of a release candidate, you can move on and
 create the real thing.
@@ -387,9 +388,9 @@ git commit --amend
 
 You will then repeat step 6 to publish the binaries to test
 
-### 15. Get 2 other maintainers to validate the pull request
+### 16. Get 2 other maintainers to validate the pull request
 
-### 16. Build final rpms and debs
+### 17. Build final rpms and debs
 
 ```bash
 docker build -t docker .
@@ -400,7 +401,7 @@ docker run \
     hack/make.sh binary build-deb build-rpm
 ```
 
-### 17. Publish final rpms and debs
+### 18. Publish final rpms and debs
 
 With the rpms and debs you built from the last step you can release them on the
 same server, or ideally, move them to a dedicated release box via scp into
@@ -424,14 +425,14 @@ docker run --rm -it --privileged \
     hack/make.sh release-deb release-rpm sign-repos generate-index-listing
 ```
 
-### 18. Upload the changed repos to wherever you host
+### 19. Upload the changed repos to wherever you host
 
 For example, above we bind mounted `/volumes/repos` as the storage for
 `DOCKER_RELEASE_DIR`. In this case `/volumes/repos/apt` can be synced with
 a specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
 a s3 bucket for the yum repo.
 
-### 19. Publish final binaries
+### 20. Publish final binaries
 
 Once they're tested and reasonably believed to be working, run against
 get.docker.com:
@@ -449,9 +450,9 @@ docker run \
     hack/release.sh
 ```
 
-### 20. Purge the cache!
+### 21. Purge the cache!
 
-### 21. Apply tag and create release
+### 22. Apply tag and create release
 
 It's very important that we don't make the tag until after the official
 release is uploaded to get.docker.com!
@@ -470,12 +471,12 @@ You can see examples in this two links:
 https://github.com/docker/docker/releases/tag/v1.8.0
 https://github.com/docker/docker/releases/tag/v1.8.0-rc3
 
-### 22. Go to github to merge the `bump_$VERSION` branch into release
+### 23. Go to github to merge the `bump_$VERSION` branch into release
 
 Don't forget to push that pretty blue button to delete the leftover
 branch afterwards!
 
-### 23. Update the docs branch
+### 24. Update the docs branch
 
 You will need to point the docs branch to the newly created release tag:
 
@@ -494,7 +495,7 @@ distributed CDN system) is flushed. The `make docs-release` command will do this
 _if_ the `DISTRIBUTION_ID` is set correctly - this will take at least 15 minutes to run
 and you can check its progress with the CDN Cloudfront Chrome addon.
 
-### 24. Create a new pull request to merge your bump commit back into master
+### 25. Create a new pull request to merge your bump commit back into master
 
 ```bash
 git checkout master
@@ -508,7 +509,7 @@ echo "https://github.com/$GITHUBUSER/docker/compare/docker:master...$GITHUBUSER:
 Again, get two maintainers to validate, then merge, then push that pretty
 blue button to delete your branch.
 
-### 25. Rejoice and Evangelize!
+### 26. Rejoice and Evangelize!
 
 Congratulations! You're done.