kotovalexarian-likes-github
/
moby--moby
mirror of https://github.com/moby/moby.git
1
0
Fork 0
Code Releases Activity

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>
This commit is contained in:
Jérôme Petazzoni 2017-03-01 09:51:23 -08:00 committed by Jerome Petazzoni
parent bb9f19503c
commit 1135eadff9
1 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
project/RELEASE-CHECKLIST.md
View File

@ -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 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" 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 - IRC on #docker, #docker-dev, #docker-maintainers
- In a comment on the pull request to notify subscribed people on GitHub - 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-dev](https://groups.google.com/forum/#!forum/docker-dev) group
- The [docker-maintainers](https://groups.google.com/a/dockerproject.org/forum/#!forum/maintainers) 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 Spend several days along with the community explicitly investing time and
resources to try and break Docker in every possible way, documenting any 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 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. 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 When you're happy with the quality of a release candidate, you can move on and
create the real thing. create the real thing.
@ -387,9 +388,9 @@ git commit --amend
You will then repeat step 6 to publish the binaries to test 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 ```bash
docker build -t docker . docker build -t docker .
@ -400,7 +401,7 @@ docker run \
hack/make.sh binary build-deb build-rpm 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 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 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 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 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 `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 specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
a s3 bucket for the yum repo. 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 Once they're tested and reasonably believed to be working, run against
get.docker.com: get.docker.com:
@ -449,9 +450,9 @@ docker run \
hack/release.sh 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 It's very important that we don't make the tag until after the official
release is uploaded to get.docker.com! 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
https://github.com/docker/docker/releases/tag/v1.8.0-rc3 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 Don't forget to push that pretty blue button to delete the leftover
branch afterwards! 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: 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 _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. 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 ```bash
git checkout master 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 Again, get two maintainers to validate, then merge, then push that pretty
blue button to delete your branch. blue button to delete your branch.
### 25. Rejoice and Evangelize! ### 26. Rejoice and Evangelize!
Congratulations! You're done. Congratulations! You're done.