diff --git a/project/RELEASE-CHECKLIST.md b/project/RELEASE-CHECKLIST.md index 9757b4ee69..159f92f329 100644 --- a/project/RELEASE-CHECKLIST.md +++ b/project/RELEASE-CHECKLIST.md @@ -205,10 +205,14 @@ open the PR against the "release" branch instead of accidentally against ### 7. Build release candidate rpms and debs +**NOTE**: It will be a lot faster if you pass a different graphdriver with +`DOCKER_GRAPHDRIVER` than `vfs`. + ```bash docker build -t docker . docker run \ --rm -t --privileged \ + -e DOCKER_GRAPHDRIVER=aufs \ -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \ docker \ hack/make.sh binary build-deb build-rpm @@ -222,42 +226,42 @@ another docker/docker directory in bundles. This next step assumes you have a checkout of the docker source code at the same commit you used to build, with the artifacts from the last step in `bundles`. +**NOTE:** If you put a space before the command your `.bash_history` will not +save it. (for the `GPG_PASSPHRASE`). + ```bash docker build -t docker . docker run --rm -it --privileged \ - -v /local/path/to/your/repos:/volumes/repos \ + -v /volumes/repos:/volumes/repos \ -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \ -v $HOME/.gnupg:/root/.gnupg \ -e DOCKER_RELEASE_DIR=/volumes/repos \ -e GPG_PASSPHRASE \ -e KEEPBUNDLE=1 \ docker \ - hack/make.sh release-deb release-rpm + hack/make.sh release-deb release-rpm sign-repos generate-index-listing ``` -### 9. Sign the repos with your GPG key +### 9. 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. -```bash -./hack/make/sign-repos -``` - -### 10. Upload the changed repos to wherever you host - -### 11. Publish release candidate binaries +### 10. Publish release candidate binaries To run this you will need access to the release credentials. Get them from the Core maintainers. -Replace "..." with the respective credentials: - ```bash docker build -t docker . +# static binaries are still pushed to s3 docker run \ - -e AWS_S3_BUCKET=test.docker.com \ # static binaries are still pushed to s3 - -e AWS_ACCESS_KEY="..." \ - -e AWS_SECRET_KEY="..." \ + -e AWS_S3_BUCKET=test.docker.com \ + -e AWS_ACCESS_KEY \ + -e AWS_SECRET_KEY \ -i -t --privileged \ docker \ hack/release.sh @@ -266,7 +270,7 @@ docker run \ It will run the test suite, build the binaries and upload to the specified bucket, so this is a good time to verify that you're running against **test**.docker.com. -### 12. Purge the cache! +### 11. Purge the cache! After the binaries are uploaded to test.docker.com and the packages are on apt.dockerproject.org and yum.dockerproject.org, make sure @@ -300,7 +304,7 @@ We recommend announcing the release candidate on: - 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 -### 13. Iterate on successive release candidates +### 12. 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 @@ -350,7 +354,7 @@ git push -f $GITHUBUSER bump_$VERSION Repeat step 6 to tag the code, publish new binaries, announce availability, and get help testing. -### 14. Finalize the bump branch +### 13. Finalize the bump branch When you're happy with the quality of a release candidate, you can move on and create the real thing. @@ -366,9 +370,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 +### 14. Get 2 other maintainers to validate the pull request -### 16. Build final rpms and debs +### 15. Build final rpms and debs ```bash docker build -t docker . @@ -379,7 +383,7 @@ docker run \ hack/make.sh binary build-deb build-rpm ``` -### 17. Publish final rpms and debs +### 16. 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 @@ -387,47 +391,49 @@ another docker/docker directory in bundles. This next step assumes you have a checkout of the docker source code at the same commit you used to build, with the artifacts from the last step in `bundles`. +**NOTE:** If you put a space before the command your `.bash_history` will not +save it. (for the `GPG_PASSPHRASE`). + ```bash docker build -t docker . docker run --rm -it --privileged \ - -v /local/path/to/your/repos:/volumes/repos \ + -v /volumes/repos:/volumes/repos \ -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \ -v $HOME/.gnupg:/root/.gnupg \ -e DOCKER_RELEASE_DIR=/volumes/repos \ -e GPG_PASSPHRASE \ -e KEEPBUNDLE=1 \ docker \ - hack/make.sh release-deb release-rpm + hack/make.sh release-deb release-rpm sign-repos generate-index-listing ``` -### 18. Sign the repos with your GPG key +### 17. 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. -```bash -./hack/make/sign-repos -``` - -### 19. Upload the changed repos to wherever you host - -### 20. Publish final binaries +### 18. Publish final binaries Once they're tested and reasonably believed to be working, run against get.docker.com: ```bash docker build -t docker . +# static binaries are still pushed to s3 docker run \ - -e AWS_S3_BUCKET=get.docker.com \ # static binaries are still pushed to s3 - -e AWS_ACCESS_KEY="..." \ - -e AWS_SECRET_KEY="..." \ + -e AWS_S3_BUCKET=get.docker.com \ + -e AWS_ACCESS_KEY \ + -e AWS_SECRET_KEY \ -i -t --privileged \ docker \ hack/release.sh ``` -### 21. Purge the cache! +### 19. Purge the cache! -### 22. Apply tag and create release +### 20. 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! @@ -446,12 +452,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 -### 23. Go to github to merge the `bump_$VERSION` branch into release +### 21. 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! -### 24. Update the docs branch +### 22. Update the docs branch You will need to point the docs branch to the newly created release tag: @@ -470,7 +476,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. -### 25. Create a new pull request to merge your bump commit back into master +### 23. Create a new pull request to merge your bump commit back into master ```bash git checkout master @@ -484,14 +490,14 @@ 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. -### 26. Update the VERSION files +### 24. Update the VERSION files Now that version X.Y.Z is out, time to start working on the next! Update the content of the `VERSION` file to be the next minor (incrementing Y) and add the `-dev` suffix. For example, after 1.5.0 release, the `VERSION` file gets updated to `1.6.0-dev` (as in "1.6.0 in the making"). -### 27. Rejoice and Evangelize! +### 25. Rejoice and Evangelize! Congratulations! You're done.