3.2 KiB
A maintainer's guide to releasing Docker
So you're in charge of a Docker release? Cool. Here's what to do.
If your experience deviates from this document, please document the changes to keep it up-to-date.
1. Pull from master and create a release branch
export VERSION=vXXX
git checkout release
git pull
git checkout -b bump_$VERSION
2. Update CHANGELOG.md
You can run this command for reference:
LAST_VERSION=$(git tag | grep -E "v[0-9\.]+$" | sort -nr | head -n 1)
git log $LAST_VERSION..HEAD
Each change should be formatted as BULLET CATEGORY: DESCRIPTION
-
BULLET is either
-,+or*, to indicate a bugfix, new feature or upgrade, respectively. -
CATEGORY should describe which part of the project is affected. Valid categories are:
- Builder
- Documentation
- Hack
- Packaging
- Remote API
- Runtime
-
DESCRIPTION: a concise description of the change that is relevant to the end-user, using the present tense. Changes should be described in terms of how they affect the user, for example "new feature X which allows Y", "fixed bug which caused X", "increased performance of Y".
EXAMPLES:
+ Builder: 'docker build -t FOO' applies the tag FOO to the newly built
container.
* Runtime: improve detection of kernel version
- Remote API: fix a bug in the optional unix socket transport
3. Change the contents of the VERSION file
4. Run all tests
docker run -privileged -lxc-conf=lxc.aa_profile=unconfined docker hack/make.sh test
5. Test the docs
Make sure that your tree includes documentation for any modified or
new features, syntax or semantic changes. Instructions for building
the docs are in docs/README.md
6. Commit and create a pull request to the "release" branch
git add VERSION CHANGELOG.md
git commit -m "Bump version to $VERSION"
git push origin bump_$VERSION
7. Get 2 other maintainers to validate the pull request
8. Apply tag
git tag -a v$VERSION # Don't forget the v!
git push --tags
Merging the pull request to the release branch will automatically
update the documentation on the "latest" revision of the docs. You
should see the updated docs 5-10 minutes after the merge. The docs
will appear on http://docs.docker.io/. For more information about
documentation releases, see docs/README.md
9. Go to github to merge the bump_$VERSION into release
10. Publish binaries
To run this you will need access to the release credentials. Get them from the infrastructure maintainers.
git checkout release
git fetch
git reset --hard origin/release
docker build -t docker .
docker run \
-e AWS_S3_BUCKET=test.docker.io \
-e AWS_ACCESS_KEY=$(cat ~/.aws/access_key) \
-e AWS_SECRET_KEY=$(cat ~/.aws/secret_key) \
-e GPG_PASSPHRASE=supersecretsesame \
-privileged -lxc-conf=lxc.aa_profile=unconfined \
-t -i \
docker \
hack/release.sh
It will build and upload the binaries on the specified bucket (you should use test.docker.io for general testing, and once everything is fine, switch to get.docker.io).
11. Rejoice!
Congratulations! You're done.