new file mode 120000

@@ -0,0 +1 @@

+project

\ No newline at end of file

deleted file mode 120000

@@ -1 +0,0 @@

-../CONTRIBUTING.md

\ No newline at end of file

deleted file mode 100644

@@ -1,17 +0,0 @@

-# Docker Governance Advisory Board Meetings

-

-In the spirit of openness, Docker created a Governance Advisory Board, and committed to make all materials and notes from the meetings of this group public.

-All output from the meetings should be considered proposals only, and are subject to the review and approval of the community and the project leadership.

-

-The materials from the first Docker Governance Advisory Board meeting, held on October 28, 2014, are available at 

-[Google Docs Folder](http://goo.gl/Alfj8r)

-

-These include:

-

-* First Meeting Notes 

-* DGAB Charter 

-* Presentation 1: Introductory Presentation, including State of The Project  

-* Presentation 2: Overall Contribution Structure/Docker Project Core Proposal 

-* Presentation 3: Long Term Roadmap/Statement of Direction 

- 

-

deleted file mode 100644

@@ -1,4 +0,0 @@

-Tianon Gravi <admwiggin@gmail.com> (@tianon)

-Cristian Staretu <cristian.staretu@gmail.com> (@unclejack)

-Tibor Vass <teabee89@gmail.com> (@tiborvass)

-dind: Jerome Petazzoni <jerome@docker.com> (@jpetazzo)

deleted file mode 100644

@@ -1,130 +0,0 @@

-# The Docker Maintainer manual

-

-## Introduction

-

-Dear maintainer. Thank you for investing the time and energy to help

-make Docker as useful as possible. Maintaining a project is difficult,

-sometimes unrewarding work. Sure, you will get to contribute cool

-features to the project. But most of your time will be spent reviewing,

-cleaning up, documenting, answering questions, and justifying design

-decisions - while everyone has all the fun! But remember - the quality

-of the maintainers' work is what distinguishes the good projects from

-the great. So please be proud of your work, even the unglamourous parts,

-and encourage a culture of appreciation and respect for *every* aspect

-of improving the project - not just the hot new features.

-

-This document is a manual for maintainers old and new. It explains what

-is expected of maintainers, how they should work, and what tools are

-available to them.

-

-This is a living document - if you see something out of date or missing,

-speak up!

-

-## What is a maintainer's responsibility?

-

-It is every maintainer's responsibility to:

-

-1. Expose a clear road map for improving their component.

-2. Deliver prompt feedback and decisions on pull requests.

-3. Be available to anyone with questions, bug reports, criticism etc.

-  on their component. This includes IRC, GitHub requests and the mailing

-  list.

-4. Make sure their component respects the philosophy, design and

-  road map of the project.

-

-## How are decisions made?

-

-Short answer: with pull requests to the Docker repository.

-

-Docker is an open-source project with an open design philosophy. This

-means that the repository is the source of truth for EVERY aspect of the

-project, including its philosophy, design, road map, and APIs. *If it's

-part of the project, it's in the repo. If it's in the repo, it's part of

-the project.*

-

-As a result, all decisions can be expressed as changes to the

-repository. An implementation change is a change to the source code. An

-API change is a change to the API specification. A philosophy change is

-a change to the philosophy manifesto, and so on.

-

-All decisions affecting Docker, big and small, follow the same 3 steps:

-

-* Step 1: Open a pull request. Anyone can do this.

-

-* Step 2: Discuss the pull request. Anyone can do this.

-

-* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do 

-this (see below "Who decides what?")

- + Accepting pull requests

-  - If the pull request appears to be ready to merge, give it a `LGTM`, which

-    stands for "Looks Good To Me".

-  - If the pull request has some small problems that need to be changed, make

-    a comment adressing the issues.

-  - If the changes needed to a PR are small, you can add a "LGTM once the

-    following comments are adressed..." this will reduce needless back and

-    forth.

-  - If the PR only needs a few changes before being merged, any MAINTAINER can

-    make a replacement PR that incorporates the existing commits and fixes the

-    problems before a fast track merge.

- + Closing pull requests

-  - If a PR appears to be abandoned, after having attempted to contact the

-    original contributor, then a replacement PR may be made.  Once the

-    replacement PR is made, any contributor may close the original one.

-  - If you are not sure if the pull request implements a good feature or you

-    do not understand the purpose of the PR, ask the contributor to provide

-    more documentation.  If the contributor is not able to adequately explain

-    the purpose of the PR, the PR may be closed by any MAINTAINER.

-  - If a MAINTAINER feels that the pull request is sufficiently architecturally

-    flawed, or if the pull request needs significantly more design discussion

-    before being considered, the MAINTAINER should close the pull request with

-    a short explanation of what discussion still needs to be had.  It is

-    important not to leave such pull requests open, as this will waste both the

-    MAINTAINER's time and the contributor's time.  It is not good to string a

-    contributor on for weeks or months, having them make many changes to a PR

-    that will eventually be rejected.

-

-## Who decides what?

-

-All decisions are pull requests, and the relevant maintainers make

-decisions by accepting or refusing pull requests. Review and acceptance

-by anyone is denoted by adding a comment in the pull request: `LGTM`.

-However, only currently listed `MAINTAINERS` are counted towards the

-required majority.

-

-Docker follows the timeless, highly efficient and totally unfair system

-known as [Benevolent dictator for

-life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with

-yours truly, Solomon Hykes, in the role of BDFL. This means that all

-decisions are made, by default, by Solomon. Since making every decision

-myself would be highly un-scalable, in practice decisions are spread

-across multiple maintainers.

-

-The relevant maintainers for a pull request can be worked out in 2 steps:

-

-* Step 1: Determine the subdirectories affected by the pull request. This

-  might be `src/registry`, `docs/source/api`, or any other part of the repo.

-

-* Step 2: Find the `MAINTAINERS` file which affects this directory. If the

-  directory itself does not have a `MAINTAINERS` file, work your way up

-  the repo hierarchy until you find one.

-

-There is also a `hacks/getmaintainers.sh` script that will print out the 

-maintainers for a specified directory.

-

-### I'm a maintainer, and I'm going on holiday

-

-Please let your co-maintainers and other contributors know by raising a pull

-request that comments out your `MAINTAINERS` file entry using a `#`.

-

-### I'm a maintainer. Should I make pull requests too?

-

-Yes. Nobody should ever push to master directly. All changes should be

-made through a pull request.

-

-### Who assigns maintainers?

-

-Solomon has final `LGTM` approval for all pull requests to `MAINTAINERS` files.

-

-### How is this process changed?

-

-Just like everything else: by making a pull request :)

deleted file mode 100644

@@ -1,336 +0,0 @@

-# Dear Packager,

-

-If you are looking to make Docker available on your favorite software

-distribution, this document is for you. It summarizes the requirements for

-building and running the Docker client and the Docker daemon.

-

-## Getting Started

-

-We want to help you package Docker successfully. Before doing any packaging, a

-good first step is to introduce yourself on the [docker-dev mailing

-list](https://groups.google.com/d/forum/docker-dev), explain what you're trying

-to achieve, and tell us how we can help. Don't worry, we don't bite! There might

-even be someone already working on packaging for the same distro!

-

-You can also join the IRC channel - #docker and #docker-dev on Freenode are both

-active and friendly.

-

-We like to refer to Tianon ("@tianon" on GitHub and "tianon" on IRC) as our

-"Packagers Relations", since he's always working to make sure our packagers have

-a good, healthy upstream to work with (both in our communication and in our

-build scripts). If you're having any kind of trouble, feel free to ping him

-directly. He also likes to keep track of what distributions we have packagers

-for, so feel free to reach out to him even just to say "Hi!"

-

-## Package Name

-

-If possible, your package should be called "docker". If that name is already

-taken, a second choice is "lxc-docker", but with the caveat that "LXC" is now an

-optional dependency (as noted below). Another possible choice is "docker.io".

-

-## Official Build vs Distro Build

-

-The Docker project maintains its own build and release toolchain. It is pretty

-neat and entirely based on Docker (surprise!). This toolchain is the canonical

-way to build Docker. We encourage you to give it a try, and if the circumstances

-allow you to use it, we recommend that you do.

-

-You might not be able to use the official build toolchain - usually because your

-distribution has a toolchain and packaging policy of its own. We get it! Your

-house, your rules. The rest of this document should give you the information you

-need to package Docker your way, without denaturing it in the process.

-

-## Build Dependencies

-

-To build Docker, you will need the following:

-

-* A recent version of git and mercurial

-* Go version 1.3 or later

-* A clean checkout of the source added to a valid [Go

-  workspace](http://golang.org/doc/code.html#Workspaces) under the path

-  *src/github.com/docker/docker* (unless you plan to use `AUTO_GOPATH`,

-  explained in more detail below).

-

-To build the Docker daemon, you will additionally need:

-

-* An amd64/x86_64 machine running Linux

-* SQLite version 3.7.9 or later

-* libdevmapper version 1.02.68-cvs (2012-01-26) or later from lvm2 version

-  2.02.89 or later

-* btrfs-progs version 3.8 or later (including commit e5cb128 from 2013-01-07)

-  for the necessary btrfs headers

-

-Be sure to also check out Docker's Dockerfile for the most up-to-date list of

-these build-time dependencies.

-

-### Go Dependencies

-

-All Go dependencies are vendored under "./vendor". They are used by the official

-build, so the source of truth for the current version of each dependency is

-whatever is in "./vendor".

-

-To use the vendored dependencies, simply make sure the path to "./vendor" is

-included in `GOPATH` (or use `AUTO_GOPATH`, as explained below).

-

-If you would rather (or must, due to distro policy) package these dependencies

-yourself, take a look at "./hack/vendor.sh" for an easy-to-parse list of the

-exact version for each.

-

-NOTE: if you're not able to package the exact version (to the exact commit) of a

-given dependency, please get in touch so we can remediate! Who knows what

-discrepancies can be caused by even the slightest deviation. We promise to do

-our best to make everybody happy.

-

-## Stripping Binaries

-

-Please, please, please do not strip any compiled binaries. This is really

-important.

-

-In our own testing, stripping the resulting binaries sometimes results in a

-binary that appears to work, but more often causes random panics, segfaults, and

-other issues. Even if the binary appears to work, please don't strip.

-

-See the following quotes from Dave Cheney, which explain this position better

-from the upstream Golang perspective.

-

-### [go issue #5855, comment #3](https://code.google.com/p/go/issues/detail?id=5855#c3)

-

-> Super super important: Do not strip go binaries or archives. It isn't tested,

-> often breaks, and doesn't work.

-

-### [launchpad golang issue #1200255, comment #8](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/8)

-

-> To quote myself: "Please do not strip Go binaries, it is not supported, not

-> tested, is often broken, and doesn't do what you want"

->

-> To unpack that a bit

->

-> * not supported, as in, we don't support it, and recommend against it when

->   asked

-> * not tested, we don't test stripped binaries as part of the build CI process

-> * is often broken, stripping a go binary will produce anywhere from no, to

->   subtle, to outright execution failure, see above

-

-### [launchpad golang issue #1200255, comment #13](https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/13)

-

-> To clarify my previous statements.

->

-> * I do not disagree with the debian policy, it is there for a good reason

-> * Having said that, it stripping Go binaries doesn't work, and nobody is

->   looking at making it work, so there is that.

->

-> Thanks for patching the build formula.

-

-## Building Docker

-

-Please use our build script ("./hack/make.sh") for all your compilation of

-Docker. If there's something you need that it isn't doing, or something it could

-be doing to make your life as a packager easier, please get in touch with Tianon

-and help us rectify the situation. Chances are good that other packagers have

-probably run into the same problems and a fix might already be in the works, but

-none of us will know for sure unless you harass Tianon about it. :)

-

-All the commands listed within this section should be run with the Docker source

-checkout as the current working directory.

-

-### `AUTO_GOPATH`

-

-If you'd rather not be bothered with the hassles that setting up `GOPATH`

-appropriately can be, and prefer to just get a "build that works", you should

-add something similar to this to whatever script or process you're using to

-build Docker:

-

-```bash

-export AUTO_GOPATH=1

-```

-

-This will cause the build scripts to set up a reasonable `GOPATH` that

-automatically and properly includes both docker/docker from the local

-directory, and the local "./vendor" directory as necessary.

-

-### `DOCKER_BUILDTAGS`

-

-If you're building a binary that may need to be used on platforms that include

-AppArmor, you will need to set `DOCKER_BUILDTAGS` as follows:

-```bash

-export DOCKER_BUILDTAGS='apparmor'

-```

-

-If you're building a binary that may need to be used on platforms that include

-SELinux, you will need to use the `selinux` build tag:

-```bash

-export DOCKER_BUILDTAGS='selinux'

-```

-

-If your version of btrfs-progs is < 3.16.1 (also called btrfs-tools), then you

-will need the following tag to not check for btrfs version headers:

-```bash

-export DOCKER_BUILDTAGS='btrfs_noversion'

-```

-

-There are build tags for disabling graphdrivers as well. By default, support

-for all graphdrivers are built in.

-

-To disable btrfs:

-```bash

-export DOCKER_BUILDTAGS='exclude_graphdriver_btrfs'

-```

-

-To disable devicemapper:

-```bash

-export DOCKER_BUILDTAGS='exclude_graphdriver_devicemapper'

-```

-

-To disable aufs:

-```bash

-export DOCKER_BUILDTAGS='exclude_graphdriver_aufs'

-```

-

-NOTE: if you need to set more than one build tag, space separate them:

-```bash

-export DOCKER_BUILDTAGS='apparmor selinux exclude_graphdriver_aufs'

-```

-

-### Static Daemon

-

-If it is feasible within the constraints of your distribution, you should

-seriously consider packaging Docker as a single static binary. A good comparison

-is Busybox, which is often packaged statically as a feature to enable mass

-portability. Because of the unique way Docker operates, being similarly static

-is a "feature".

-

-To build a static Docker daemon binary, run the following command (first

-ensuring that all the necessary libraries are available in static form for

-linking - see the "Build Dependencies" section above, and the relevant lines

-within Docker's own Dockerfile that set up our official build environment):

-

-```bash

-./hack/make.sh binary

-```

-

-This will create a static binary under

-"./bundles/$VERSION/binary/docker-$VERSION", where "$VERSION" is the contents of

-the file "./VERSION". This binary is usually installed somewhere like

-"/usr/bin/docker".

-

-### Dynamic Daemon / Client-only Binary

-

-If you are only interested in a Docker client binary, set `DOCKER_CLIENTONLY` to a non-empty value using something similar to the following: (which will prevent the extra step of compiling dockerinit)

-

-```bash

-export DOCKER_CLIENTONLY=1

-```

-

-If you need to (due to distro policy, distro library availability, or for other

-reasons) create a dynamically compiled daemon binary, or if you are only

-interested in creating a client binary for Docker, use something similar to the

-following:

-

-```bash

-./hack/make.sh dynbinary

-```

-

-This will create "./bundles/$VERSION/dynbinary/docker-$VERSION", which for

-client-only builds is the important file to grab and install as appropriate.

-

-For daemon builds, you will also need to grab and install

-"./bundles/$VERSION/dynbinary/dockerinit-$VERSION", which is created from the

-minimal set of Docker's codebase that _must_ be compiled statically (and is thus

-a pure static binary). The acceptable locations Docker will search for this file

-are as follows (in order):

-

-* as "dockerinit" in the same directory as the daemon binary (ie, if docker is

-  installed at "/usr/bin/docker", then "/usr/bin/dockerinit" will be the first

-  place this file is searched for)

-* "/usr/libexec/docker/dockerinit" or "/usr/local/libexec/docker/dockerinit"

-  ([FHS 3.0 Draft](http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibexec))

-* "/usr/lib/docker/dockerinit" or "/usr/local/lib/docker/dockerinit" ([FHS

-  2.3](http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA))

-

-If (and please, only if) one of the paths above is insufficient due to distro

-policy or similar issues, you may use the `DOCKER_INITPATH` environment variable

-at compile-time as follows to set a different path for Docker to search:

-

-```bash

-export DOCKER_INITPATH=/usr/lib/docker.io/dockerinit

-```

-

-If you find yourself needing this, please don't hesitate to reach out to Tianon

-to see if it would be reasonable or helpful to add more paths to Docker's list,

-especially if there's a relevant standard worth referencing (such as the FHS).

-

-Also, it goes without saying, but for the purposes of the daemon please consider

-these two binaries ("docker" and "dockerinit") as if they were a single unit.

-Mixing and matching can cause undesired consequences, and will fail to run

-properly.

-

-## System Dependencies

-

-### Runtime Dependencies

-

-To function properly, the Docker daemon needs the following software to be

-installed and available at runtime:

-

-* iptables version 1.4 or later

-* procps (or similar provider of a "ps" executable)

-* e2fsprogs version 1.4.12 or later (in use: mkfs.ext4, mkfs.xfs, tune2fs)

-* XZ Utils version 4.9 or later

-* a [properly

-  mounted](https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount)

-  cgroupfs hierarchy (having a single, all-encompassing "cgroup" mount point

-  [is](https://github.com/docker/docker/issues/2683)

-  [not](https://github.com/docker/docker/issues/3485)

-  [sufficient](https://github.com/docker/docker/issues/4568))

-

-Additionally, the Docker client needs the following software to be installed and

-available at runtime:

-

-* Git version 1.7 or later

-

-### Kernel Requirements

-

-The Docker daemon has very specific kernel requirements. Most pre-packaged

-kernels already include the necessary options enabled. If you are building your

-own kernel, you will either need to discover the options necessary via trial and

-error, or check out the [Gentoo

-ebuild](https://github.com/tianon/docker-overlay/blob/master/app-emulation/docker/docker-9999.ebuild),

-in which a list is maintained (and if there are any issues or discrepancies in

-that list, please contact Tianon so they can be rectified).

-

-Note that in client mode, there are no specific kernel requirements, and that

-the client will even run on alternative platforms such as Mac OS X / Darwin.

-

-### Optional Dependencies

-

-Some of Docker's features are activated by using optional command-line flags or

-by having support for them in the kernel or userspace. A few examples include:

-

-* LXC execution driver (requires version 1.0 or later of the LXC utility scripts)

-* AUFS graph driver (requires AUFS patches/support enabled in the kernel, and at

-  least the "auplink" utility from aufs-tools)

-* BTRFS graph driver (requires BTRFS support enabled in the kernel)

-

-## Daemon Init Script

-

-Docker expects to run as a daemon at machine startup. Your package will need to

-include a script for your distro's process supervisor of choice. Be sure to

-check out the "contrib/init" folder in case a suitable init script already

-exists (and if one does not, contact Tianon about whether it might be

-appropriate for your distro's init script to live there too!).

-

-In general, Docker should be run as root, similar to the following:

-

-```bash

-docker -d

-```

-

-Generally, a `DOCKER_OPTS` variable of some kind is available for adding more

-flags (such as changing the graph driver to use BTRFS, switching the location of

-"/var/lib/docker", etc).

-

-## Communicate

-

-As a final note, please do feel free to reach out to Tianon at any time for

-pretty much anything. He really does love hearing from our packagers and wants

-to make sure we're not being a "hostile upstream". As should be a given, we

-appreciate the work our packagers do to make sure we have broad distribution!

deleted file mode 100644

@@ -1,19 +0,0 @@

-# Docker principles

-

-In the design and development of Docker we try to follow these principles:

-

-(Work in progress)

-

-* Don't try to replace every tool. Instead, be an ingredient to improve them.

-* Less code is better.

-* Less components is better. Do you really need to add one more class?

-* 50 lines of straightforward, readable code is better than 10 lines of magic that nobody can understand.

-* Don't do later what you can do now. "//FIXME: refactor" is not acceptable in new code.

-* When hesitating between 2 options, choose the one that is easier to reverse.

-* No is temporary, Yes is forever. If you're not sure about a new feature, say no. You can change your mind later.

-* Containers must be portable to the greatest possible number of machines. Be suspicious of any change which makes machines less interchangeable.

-* The less moving parts in a container, the better.

-* Don't merge it unless you document it.

-* Don't document it unless you can keep it up-to-date.

-* Don't merge it unless you test it!

-* Everyone's problem is slightly different. Focus on the part that is the same for everyone, and solve that.

deleted file mode 100644

@@ -1,24 +0,0 @@

-# Hacking on Docker

-

-The hack/ directory holds information and tools for everyone involved in the process of creating and

-distributing Docker, specifically:

-

-## Guides

-

-If you're a *contributor* or aspiring contributor, you should read CONTRIBUTORS.md.

-

-If you're a *maintainer* or aspiring maintainer, you should read MAINTAINERS.md.

-

-If you're a *packager* or aspiring packager, you should read PACKAGERS.md.

-

-If you're a maintainer in charge of a *release*, you should read RELEASE-CHECKLIST.md.

-

-## Roadmap

-

-A high-level roadmap is available at ROADMAP.md.

-

-

-## Build tools

-

-make.sh is the primary build tool for docker. It is used for compiling the official binary,

-running the test suite, and pushing releases.

deleted file mode 100644

@@ -1,303 +0,0 @@

-# Release Checklist

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

-

-It is important to note that this document assumes that the git remote in your

-repository that corresponds to "https://github.com/docker/docker" is named

-"origin".  If yours is not (for example, if you've chosen to name it "upstream"

-or something similar instead), be sure to adjust the listed snippets for your

-local environment accordingly.  If you are not sure what your upstream remote is

-named, use a command like `git remote -v` to find out.

-

-If you don't have an upstream remote, you can add one easily using something

-like:

-

-```bash

-export GITHUBUSER="YOUR_GITHUB_USER"

-git remote add origin https://github.com/docker/docker.git

-git remote add $GITHUBUSER git@github.com:$GITHUBUSER/docker.git

-```

-

-### 1. Pull from master and create a release branch

-

-Note: Even for major releases, all of X, Y and Z in vX.Y.Z must be specified (e.g. v1.0.0).

-

-```bash

-export VERSION=vX.Y.Z

-git fetch origin

-git branch -D release || true

-git checkout --track origin/release

-git checkout -b bump_$VERSION

-```

-

-If it's a regular release, we usually merge master.

-```bash

-git merge origin/master

-```

-

-Otherwise, if it is a hotfix release, we cherry-pick only the commits we want.

-```bash

-# get the commits ids we want to cherry-pick

-git log

-# cherry-pick the commits starting from the oldest one, without including merge commits

-git cherry-pick <commit-id>

-git cherry-pick <commit-id>

-...

-```

-

-### 2. Update CHANGELOG.md

-

-You can run this command for reference with git 2.0:

-

-```bash

-git fetch --tags

-LAST_VERSION=$(git tag -l --sort=-version:refname "v*" | grep -E 'v[0-9\.]+$' | head -1)

-git log --stat $LAST_VERSION..bump_$VERSION

-```

-

-If you don't have git 2.0 but have a sort command that supports `-V`:

-```bash

-git fetch --tags

-LAST_VERSION=$(git tag -l | grep -E 'v[0-9\.]+$' | sort -rV | head -1)

-git log --stat $LAST_VERSION..bump_$VERSION

-```

-

-If releasing a major version (X or Y increased in vX.Y.Z), simply listing notable user-facing features is sufficient.

-```markdown

-#### Notable features since <last major version>

-* New docker command to do something useful

-* Remote API change (deprecating old version)

-* Performance improvements in some usecases

-* ...

-```

-

-For minor releases (only Z increases in vX.Y.Z), provide a list of user-facing changes.

-Each change should be listed under a category heading formatted as `#### CATEGORY`.

-

-`CATEGORY` should describe which part of the project is affected.

-  Valid categories are:

-  * Builder

-  * Documentation

-  * Hack

-  * Packaging

-  * Remote API

-  * Runtime

-  * Other (please use this category sparingly)

-

-Each change should be formatted as `BULLET DESCRIPTION`, given:

-

-* BULLET: either `-`, `+` or `*`, to indicate a bugfix, new feature or

-  upgrade, respectively.

-

-* 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 "Add new feature X which allows Y",

-  "Fix bug which caused X", "Increase performance of Y".

-

-EXAMPLES:

-

-```markdown

-## 0.3.6 (1995-12-25)

-

-#### Builder

-

-+ 'docker build -t FOO .' applies the tag FOO to the newly built image

-

-#### Remote API

-

-- Fix a bug in the optional unix socket transport

-

-#### Runtime

-

-* Improve detection of kernel version

-```

-

-If you need a list of contributors between the last major release and the

-current bump branch, use something like:

-```bash

-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

-

-```bash

-echo ${VERSION#v} > VERSION

-```

-

-### 4. Test the docs

-

-Make sure that your tree includes documentation for any modified or

-new features, syntax or semantic changes.

-

-To test locally:

-

-```bash

-make docs

-```

-

-To make a shared test at http://beta-docs.docker.io:

-

-(You will need the `awsconfig` file added to the `docs/` dir)

-

-```bash

-make AWS_S3_BUCKET=beta-docs.docker.io BUILD_ROOT=yes docs-release

-```

-

-### 5. Commit and create a pull request to the "release" branch

-

-```bash

-git add VERSION CHANGELOG.md

-git commit -m "Bump version to $VERSION"

-git push $GITHUBUSER bump_$VERSION

-echo "https://github.com/$GITHUBUSER/docker/compare/docker:release...$GITHUBUSER:bump_$VERSION?expand=1"

-```

-

-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. Get 2 other maintainers to validate the pull request

-

-### 7. Publish binaries

-

-To run this you will need access to the release credentials. Get them from the Core maintainers.

-

-Replace "..." with the respective credentials:

-

-```bash

-docker build -t docker .

-docker run \

-       -e AWS_S3_BUCKET=test.docker.com \

-       -e AWS_ACCESS_KEY="..." \

-       -e AWS_SECRET_KEY="..." \

-       -e GPG_PASSPHRASE="..." \

-       -i -t --privileged \

-       docker \

-       hack/release.sh

-```

-

-It will run the test suite, build the binaries and packages,

-and upload to the specified bucket (you should use test.docker.com for

-general testing, and once everything is fine, switch to get.docker.com as

-noted below).

-

-After the binaries and packages are uploaded to test.docker.com, make sure

-they get tested in both Ubuntu and Debian for any obvious installation

-issues or runtime issues.

-

-Announcing on IRC in both `#docker` and `#docker-dev` is a great way to get

-help testing!  An easy way to get some useful links for sharing:

-

-```bash

-echo "Ubuntu/Debian: https://test.docker.com/ubuntu or curl -sSL https://test.docker.com/ | sh"

-echo "Linux 64bit binary: https://test.docker.com/builds/Linux/x86_64/docker-${VERSION#v}"

-echo "Darwin/OSX 64bit client binary: https://test.docker.com/builds/Darwin/x86_64/docker-${VERSION#v}"

-echo "Darwin/OSX 32bit client binary: https://test.docker.com/builds/Darwin/i386/docker-${VERSION#v}"

-echo "Linux 64bit tgz: https://test.docker.com/builds/Linux/x86_64/docker-${VERSION#v}.tgz"

-```

-

-Once they're tested and reasonably believed to be working, run against

-get.docker.com:

-

-```bash

-docker run \

-       -e AWS_S3_BUCKET=get.docker.com \

-       -e AWS_ACCESS_KEY="..." \

-       -e AWS_SECRET_KEY="..." \

-       -e GPG_PASSPHRASE="..." \

-       -i -t --privileged \

-       docker \

-       hack/release.sh

-```

-

-### 8. Breakathon

-

-Spend several days along with the community explicitly investing time and

-resources to try and break Docker in every possible way, documenting any

-findings pertinent to the release.  This time should be spent testing and

-finding ways in which the release might have caused various features or upgrade

-environments to have issues, not coding.  During this time, the release is in

-code freeze, and any additional code changes will be pushed out to the next

-release.

-

-It should include various levels of breaking Docker, beyond just using Docker

-by the book.

-

-Any issues found may still remain issues for this release, but they should be

-documented and give appropriate warnings.

-

-### 9. Apply tag

-

-It's very important that we don't make the tag until after the official

-release is uploaded to get.docker.com!

-

-```bash

-git tag -a $VERSION -m $VERSION bump_$VERSION

-git push origin $VERSION

-```

-

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

-

-If this is a MAJOR.MINOR.0 release, you need to make an branch for the previous release's

-documentation:

-

-```bash

-git checkout -b docs-$PREVIOUS_MAJOR_MINOR docs

-git fetch

-git reset --hard origin/docs

-git push -f origin docs-$PREVIOUS_MAJOR_MINOR

-```

-

-You will need the `awsconfig` file added to the `docs/` directory to contain the

-s3 credentials for the bucket you are deploying to.

-

-```bash

-git checkout -b docs release || git checkout docs

-git fetch

-git reset --hard origin/release

-git push -f origin docs

-make AWS_S3_BUCKET=docs.docker.com BUILD_ROOT=yes docs-release

-```

-

-The docs will appear on http://docs.docker.com/ (though there may be cached

-versions, so its worth checking http://docs.docker.com.s3-website-us-east-1.amazonaws.com/).

-For more information about documentation releases, see `docs/README.md`.

-

-Ask Sven, or JohnC to invalidate the cloudfront cache using the CND Planet chrome applet.

-

-### 12. Create a new pull request to merge release back into master

-

-```bash

-git checkout master

-git fetch

-git reset --hard origin/master

-git merge origin/release

-git checkout -b merge_release_$VERSION

-echo ${VERSION#v}-dev > VERSION

-git add VERSION

-git commit -m "Change version to $(cat VERSION)"

-git push $GITHUBUSER merge_release_$VERSION