docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Early API version bump 

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
This commit is contained in:
Arnaud Porterie 2015-04-20 11:24:28 -07:00
parent b5584ec24a
commit a8253ec7e7
1 changed files with 25 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
project/RELEASE-CHECKLIST.md
View File

@ -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: 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 Obviously, you'll need to adjust version numbers as necessary. If you just need
a count, add a simple `| wc -l`. 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 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: 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 echo ${RC_VERSION#v} > VERSION
``` ```
### 4. Test the docs ### 5. Test the docs
Make sure that your tree includes documentation for any modified or Make sure that your tree includes documentation for any modified or
new features, syntax or semantic changes. 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 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 ```bash
git add VERSION CHANGELOG.md 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 open the PR against the "release" branch instead of accidentally against
"master" (like so many brave souls before you already have). "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 To run this you will need access to the release credentials. Get them from the
Core maintainers. 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 - 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 - 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 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
@ -269,7 +279,7 @@ git push -f $GITHUBUSER bump_$VERSION
Repeat step 6 to tag the code, publish new binaries, announce availability, and Repeat step 6 to tag the code, publish new binaries, announce availability, and
get help testing. 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 When you're happy with the quality of a release candidate, you can move on and
create the real thing. create the real thing.
@ -285,9 +295,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
### 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 Once they're tested and reasonably believed to be working, run against
get.docker.com: get.docker.com:
@ -303,7 +313,7 @@ docker run \
hack/release.sh hack/release.sh
``` ```
### 9. Apply tag ### 12. Apply tag
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!
@ -313,12 +323,12 @@ git tag -a $VERSION -m $VERSION bump_$VERSION
git push origin $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 Don't forget to push that pretty blue button to delete the leftover
branch afterwards! 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 If this is a MAJOR.MINOR.0 release, you need to make an branch for the previous release's
documentation: 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 _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. 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 ```bash
git checkout master 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 Again, get two maintainers to validate, then merge, then push that pretty
blue button to delete your branch. 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 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 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 `-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"). 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 ### 17. Rejoice and Evangelize!
and bumping the version number (in both the file's name and content).
### 14. Rejoice and Evangelize!
Congratulations! You're done. Congratulations! You're done.