From a8253ec7e7ec13c81d5195ddfe3cf2571ce6afff Mon Sep 17 00:00:00 2001 From: Arnaud Porterie Date: Mon, 20 Apr 2015 11:24:28 -0700 Subject: [PATCH] Early API version bump Signed-off-by: Arnaud Porterie --- project/RELEASE-CHECKLIST.md | 43 +++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 18 deletions(-) diff --git a/project/RELEASE-CHECKLIST.md b/project/RELEASE-CHECKLIST.md index 8a2070e58d..d2b9650805 100644 --- a/project/RELEASE-CHECKLIST.md +++ b/project/RELEASE-CHECKLIST.md @@ -49,7 +49,17 @@ git cherry-pick ... ``` -### 2. Update CHANGELOG.md +### 2. Bump the API version on master + +We don't want to stop contributions to master just because we are releasing. At +the same time, now that the release branch exists, we don't want API changes to +go to the now frozen API version. + +Create a new entry in `docs/sources/reference/api/` by copying the latest and +bumping the version number (in both the file's name and content), and submit +this in a PR against master. + +### 3. Update CHANGELOG.md You can run this command for reference with git 2.0: @@ -124,7 +134,7 @@ git log --format='%aN <%aE>' v0.7.0...bump_v0.8.0 | sort -uf Obviously, you'll need to adjust version numbers as necessary. If you just need a count, add a simple `| wc -l`. -### 3. Change the contents of the VERSION file +### 4. Change the contents of the VERSION file Before the big thing, you'll want to make successive release candidates and get people to test. The release candidate number `N` should be part of the version: @@ -134,7 +144,7 @@ export RC_VERSION=${VERSION}-rcN echo ${RC_VERSION#v} > VERSION ``` -### 4. Test the docs +### 5. Test the docs Make sure that your tree includes documentation for any modified or new features, syntax or semantic changes. @@ -153,7 +163,7 @@ To make a shared test at https://beta-docs.docker.io: make AWS_S3_BUCKET=beta-docs.docker.io BUILD_ROOT=yes docs-release ``` -### 5. Commit and create a pull request to the "release" branch +### 6. Commit and create a pull request to the "release" branch ```bash git add VERSION CHANGELOG.md @@ -166,7 +176,7 @@ That last command will give you the proper link to visit to ensure that you open the PR against the "release" branch instead of accidentally against "master" (like so many brave souls before you already have). -### 6. Publish release candidate binaries +### 7. Publish release candidate binaries To run this you will need access to the release credentials. Get them from the Core maintainers. @@ -219,7 +229,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 -### 7. Iterate on successive release candidates +### 8. 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 @@ -269,7 +279,7 @@ git push -f $GITHUBUSER bump_$VERSION Repeat step 6 to tag the code, publish new binaries, announce availability, and get help testing. -### 8. Finalize the bump branch +### 9. Finalize the bump branch When you're happy with the quality of a release candidate, you can move on and create the real thing. @@ -285,9 +295,9 @@ git commit --amend You will then repeat step 6 to publish the binaries to test -### 9. Get 2 other maintainers to validate the pull request +### 10. Get 2 other maintainers to validate the pull request -### 10. Publish final binaries +### 11. Publish final binaries Once they're tested and reasonably believed to be working, run against get.docker.com: @@ -303,7 +313,7 @@ docker run \ hack/release.sh ``` -### 9. Apply tag +### 12. Apply tag It's very important that we don't make the tag until after the official release is uploaded to get.docker.com! @@ -313,12 +323,12 @@ git tag -a $VERSION -m $VERSION bump_$VERSION git push origin $VERSION ``` -### 10. Go to github to merge the `bump_$VERSION` branch into release +### 13. 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! -### 11. Update the docs branch +### 14. Update the docs branch If this is a MAJOR.MINOR.0 release, you need to make an branch for the previous release's documentation: @@ -350,7 +360,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 addin. -### 12. Create a new pull request to merge your bump commit back into master +### 15. Create a new pull request to merge your bump commit back into master ```bash git checkout master @@ -364,17 +374,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. -### 13. Update the API docs and VERSION files +### 16. 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"). -Also create a new entry in `docs/sources/reference/api/` by copying the latest -and bumping the version number (in both the file's name and content). - -### 14. Rejoice and Evangelize! +### 17. Rejoice and Evangelize! Congratulations! You're done.