@@ -49,7 +49,17 @@ git cherry-pick <commit-id>

 ...

 ```

-### 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.