From 1135eadff95f15ca250cf87df7a0eae0324f619f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= Date: Wed, 1 Mar 2017 09:51:23 -0800 Subject: [PATCH] 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 --- project/RELEASE-CHECKLIST.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/project/RELEASE-CHECKLIST.md b/project/RELEASE-CHECKLIST.md index 84848cae2b..5c73b5826c 100644 --- a/project/RELEASE-CHECKLIST.md +++ b/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.