|
|
@@ -0,0 +1,78 @@
|
|
|
+# Docker Release Process
|
|
|
+
|
|
|
+This document describes how the Docker project is released. The Docker project
|
|
|
+release process targets the Engine, Compose, Kitematic, Machine, Swarm,
|
|
|
+Distribution, Notary and their underlying dependencies (libnetwork, libkv,
|
|
|
+etc...).
|
|
|
+
|
|
|
+Step-by-step technical details of the process are described in
|
|
|
+[RELEASE-CHECKLIST.md](https://github.com/docker/docker/blob/master/project/RELEASE-CHECKLIST.md).
|
|
|
+
|
|
|
+## Release cycle
|
|
|
+
|
|
|
+The Docker project follows a **time-based release cycle** and ships every nine
|
|
|
+weeks. A release cycle starts the same day the previous release cycle ends.
|
|
|
+
|
|
|
+The first six weeks of the cycle are dedicated to development and review. During
|
|
|
+this phase, new features and bugfixes submitted to any of the projects are
|
|
|
+**eligible** to be shipped as part of the next release. No changeset submitted
|
|
|
+during this period is however guaranteed to be merged for the current release
|
|
|
+cycle.
|
|
|
+
|
|
|
+## The freeze period
|
|
|
+
|
|
|
+Six weeks after the beginning of the cycle, the codebase is officially frozen
|
|
|
+and the codebase reaches a state close to the final release. A Release Candidate
|
|
|
+(RC) gets created at the same time. The freeze period is used to find bugs and
|
|
|
+get feedback on the state of the RC before the release.
|
|
|
+
|
|
|
+During this freeze period, while the `master` branch will continue its normal
|
|
|
+development cycle, no new features are accepted into the RC. As bugs are fixed
|
|
|
+in `master` the release owner will selectively 'cherry-pick' critical ones to
|
|
|
+be included into the RC. As the RC changes, new ones are made available for the
|
|
|
+community to test and review.
|
|
|
+
|
|
|
+This period lasts for three weeks.
|
|
|
+
|
|
|
+## How to maximize chances of being merged before the freeze date?
|
|
|
+
|
|
|
+First of all, there is never a guarantee that a specific changeset is going to
|
|
|
+be merged. However there are different actions to follow to maximize the chances
|
|
|
+for a changeset to be merged:
|
|
|
+
|
|
|
+- The team gives priority to review the PRs aligned with the Roadmap (usually
|
|
|
+defined by a ROADMAP.md file at the root of the repository).
|
|
|
+- The earlier a PR is opened, the more time the maintainers have to review. For
|
|
|
+example, if a PR is opened the day before the freeze date, it’s very unlikely
|
|
|
+that it will be merged for the release.
|
|
|
+- Constant communication with the maintainers (mailing-list, IRC, Github issues,
|
|
|
+etc.) allows to get early feedback on the design before getting into the
|
|
|
+implementation, which usually reduces the time needed to discuss a changeset.
|
|
|
+- If the code is commented, fully tested and by extension follows every single
|
|
|
+rules defined by the [CONTRIBUTING guide](
|
|
|
+https://github.com/docker/docker/blob/master/CONTRIBUTING.md), this will help
|
|
|
+the maintainers by speeding up the review.
|
|
|
+
|
|
|
+## The release
|
|
|
+
|
|
|
+At the end of the freeze (nine weeks after the start of the cycle), all the
|
|
|
+projects are released together.
|
|
|
+
|
|
|
+```
|
|
|
+ Codebase Release
|
|
|
+Start of is frozen (end of the
|
|
|
+the Cycle (7th week) 9th week)
|
|
|
++---------------------------------------+---------------------+
|
|
|
+| | |
|
|
|
+| Development phase | Freeze phase |
|
|
|
+| | |
|
|
|
++---------------------------------------+---------------------+
|
|
|
+ 6 weeks 3 weeks
|
|
|
+<---------------------------------------><-------------------->
|
|
|
+```
|
|
|
+
|
|
|
+## Exceptions
|
|
|
+
|
|
|
+If a critical issue is found at the end of the freeze period and more time is
|
|
|
+needed to address it, the release will be pushed back. When a release gets
|
|
|
+pushed back, the next release cycle gets delayed as well.
|
Arnaud Porterie