3 Commit merging: scope and cadence
4 ==================================
6 Commits are merged into branches according to criteria specific to each phase
7 of the Ceph release lifecycle. This chapter codifies these criteria.
9 Development releases (i.e. x.0.z)
10 ---------------------------------
21 Features are merged to the *main* branch. Bug fixes should be merged to the
22 corresponding named branch (e.g. *nautilus* for 14.0.z, *pacific* for 16.0.z,
23 etc.). However, this is not mandatory - bug fixes and documentation
24 enhancements can be merged to the *main* branch as well, since the *main*
25 branch is itself occasionally merged to the named branch during the development
26 releases phase. In either case, if a bug fix is important it can also be
27 flagged for backport to one or more previous stable releases.
32 After each stable release, candidate branches for previous releases enter
33 phase 2 (see below). For example: the *jewel* named branch was created when
34 the *infernalis* release candidates entered phase 2. From this point on,
35 *main* was no longer associated with *infernalis*. After he named branch of
36 the next stable release is created, *main* will be occasionally merged into
42 * The latest stable release branch is merged periodically into main.
43 * The main branch is merged periodically into the branch of the stable release.
44 * The main is merged into the stable release branch
45 immediately after each development (x.0.z) release.
47 Stable release candidates (i.e. x.1.z) phase 1
48 ----------------------------------------------
58 The stable release branch (e.g. *jewel* for 10.0.z, *luminous*
59 for 12.0.z, etc.) or *main*. Bug fixes should be merged to the named
60 branch corresponding to the stable release candidate (e.g. *jewel* for
61 10.1.z) or to *main*. During this phase, all commits to *main* will be
62 merged to the named branch, and vice versa. In other words, it makes
63 no difference whether a commit is merged to the named branch or to
64 *main* - it will make it into the next release candidate either way.
69 After the first stable release candidate is published, i.e. after the
70 x.1.0 tag is set in the release branch.
75 * The stable release branch is merged periodically into *main*.
76 * The *main* branch is merged periodically into the stable release branch.
77 * The *main* branch is merged into the stable release branch
78 immediately after each x.1.z release candidate.
80 Stable release candidates (i.e. x.1.z) phase 2
81 ----------------------------------------------
91 The stable release branch (e.g. *mimic* for 13.0.z, *octopus* for 15.0.z
92 ,etc.). During this phase, all commits to the named branch will be merged into
93 *main*. Cherry-picking to the named branch during release candidate phase 2
94 is performed manually since the official backporting process begins only when
95 the release is pronounced "stable".
100 After the CLT announces that it is time for phase 2 to happen.
105 * The stable release branch is occasionally merged into main.
107 Stable releases (i.e. x.2.z)
108 ----------------------------
114 * Features are sometime accepted
115 * Commits should be cherry-picked from *main* when possible
116 * Commits that are not cherry-picked from *main* must pertain to a bug unique to
118 * See also the `backport HOWTO`_ document
120 .. _`backport HOWTO`:
121 http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO#HOWTO
126 The stable release branch (*hammer* for 0.94.x, *infernalis* for 9.2.x,
132 After the stable release is published, i.e. after the "vx.2.0" tag is set in