Early API version bump

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>

project/RELEASE-CHECKLIST.md

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