Docker CE

⚠️ This repository is now deprecated and will be archived (Docker CE itself is NOT deprecated) ⚠️

Starting with the Docker 20.10 release, packages for the Docker Engine andDocker CLI are built directly from their respective source repositories insteadof from this repository.

Practically this means:

1. This repository is no longer the “source of truth” for Docker CE builds.
2. The commit SHA and tag for Docker CLI build will come from thedocker/cli repository and the commit SHA andtag for the Docker Engine will come from themoby/moby repository.
3. Release branches for the Engine, CLI, and packaging will be maintained ontheir respective repositories.
4. Updates will stop being made to this repository and it will be archived inthe future.
5. Changelog is nowRelease Notes.
6. The master branch of this repository will be emptied when the repositoryis archived.

Description

This repository hosts open source components of Docker CE products. Themaster branch serves to unify the upstream components on a regularbasis. Long-lived release branches host the code that goes into a productversion for the lifetime of the product.

This repository is solely maintained by Docker, Inc.

Issues

There are separate issue-tracking repos for the end user Docker CEproducts specialized for a platform. Find your issue or file a new issuefor the platform you are using:

• https://github.com/docker/for-linux
• https://github.com/docker/for-mac
• https://github.com/docker/for-win

Submitting pull requests

This repository does not accept PRs for files under the components directory directly.To contribute to the files under the components directory, see CONTRIBUTING.md .

Unifying upstream sources

The master branch is a combination of components adapted fromdifferent upstream git repos into a unified directory structure using themoby-componentstool.

You can view the upstream git repos in thecomponents.conf file. Each component is isolated intoits own directory under the components directory.

The tool will import each component git history within the appropriate path.

For example, this shows a commitis imported into the component engine frommoby/moby@a27b4b8into the components/engine directory.

commit 5c70746915d4589a692cbe50a43cf619ed0b7152
Author: Andrea Luzzardi <aluzzardi@gmail.com>
Date:   Sat Jan 19 00:13:39 2013

    Initial commit
    Upstream-commit: a27b4b8cb8e838d03a99b6d2b30f76bdaf2f9e5d
    Component: engine

 components/engine/container.go       | 203 ++++++++++++++++++++++++++++...
 components/engine/container_test.go  | 186 ++++++++++++++++++++++++++++...
 components/engine/docker.go          | 112 ++++++++++++++++++++++++++++...
 components/engine/docker_test.go     | 175 ++++++++++++++++++++++++++++...
 components/engine/filesystem.go      |  52 ++++++++++++++++++++++++++++...
 components/engine/filesystem_test.go |  35 +++++++++++++++++++++++++++
 components/engine/lxc_template.go    |  94 ++++++++++++++++++++++++++++...
 components/engine/state.go           |  48 ++++++++++++++++++++++++++++...
 components/engine/utils.go           | 115 ++++++++++++++++++++++++++++...
 components/engine/utils_test.go      | 126 ++++++++++++++++++++++++++++...
 10 files changed, 1146 insertions(+)

Updates to master branch

Main development of new features should be directed towards the upstreamgit repos. The master branch of this repo will periodically pull in newchanges from upstream to provide a point for integration.

Branching for release

When a release is started for Docker CE, a new branch will be createdfrom master. Branch names will be YY.MM to represent the time-basedrelease version of the product, e.g. 17.06.

Adding fixes to release branch

Note: every commit of a fix should affect files only within one componentdirectory.

Fix available upstream

A PR cherry-picking the necessary commits should be created againstthe release branch. If the the cherry-pick cannot be applied cleanly,the logic of the fix should be ported manually.

No fix yet

First create the PR with the fix for the release branch. Once the fix hasbeen merged, be sure to port the fix to the respective upstream git repo.

Release tags

There will be a git tag for each release candidate (RC) and generalavailability (GA) release. The tag will only point to commits on releasebranches.