|
@@ -226,12 +226,10 @@ review session. The goal of that session is to agree on one of the following out
|
|
## Milestones
|
|
## Milestones
|
|
|
|
|
|
Typically, every merged pull request get shipped naturally with the next release cut from the
|
|
Typically, every merged pull request get shipped naturally with the next release cut from the
|
|
-`master` branch (either the next minor or major version, as indicated by the
|
|
|
|
-[`VERSION`](https://github.com/docker/docker/blob/master/VERSION) file at the root of the
|
|
|
|
-repository). However, the time-based nature of the release process provides no guarantee that a
|
|
|
|
-given pull request will get merged in time. In other words, all open pull requests are implicitly
|
|
|
|
-considered part of the next minor or major release milestone, and this won't be materialized on
|
|
|
|
-GitHub.
|
|
|
|
|
|
+`master` branch (either the next minor or major version). However, the time-based nature of the
|
|
|
|
+release process provides no guarantee that a given pull request will get merged in time. In other
|
|
|
|
+words, all open pull requests are implicitly considered part of the next minor or major release
|
|
|
|
+milestone, and this won't be materialized on GitHub.
|
|
|
|
|
|
A merged pull request must be attached to the milestone corresponding to the release in which it
|
|
A merged pull request must be attached to the milestone corresponding to the release in which it
|
|
will be shipped: this is both useful for tracking, and to help the release manager with the
|
|
will be shipped: this is both useful for tracking, and to help the release manager with the
|