ceph/doc/dev/developer_guide/merging.rst

   1 .. _merging:
   2
   3 Commit merging:  scope and cadence
   4 ==================================
   5
   6 Commits are merged into branches according to criteria specific to each phase
   7 of the Ceph release lifecycle. This chapter codifies these criteria.
   8
   9 Development releases (i.e. x.0.z)
  10 ---------------------------------
  11
  12 What ?
  13 ^^^^^^
  14
  15 * Features
  16 * Bug fixes
  17
  18 Where ?
  19 ^^^^^^^
  20
  21 Features are merged to the *master* 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 *master* branch as well, since the *master*
  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.
  28
  29 When ?
  30 ^^^^^^
  31
  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 *master* was no longer associated with *infernalis*. After he named branch of
  36 the next stable release is created, *master* will be occasionally merged into
  37 it.
  38
  39 Branch merges
  40 ^^^^^^^^^^^^^
  41
  42 * The latest stable release branch is merged periodically into master.
  43 * The master branch is merged periodically into the branch of the stable release.
  44 * The master is merged into the stable release branch
  45   immediately after each development (x.0.z) release.
  46
  47 Stable release candidates (i.e. x.1.z) phase 1
  48 ----------------------------------------------
  49
  50 What ?
  51 ^^^^^^
  52
  53 * Bug fixes only
  54
  55 Where ?
  56 ^^^^^^^
  57
  58 The stable release branch (e.g. *jewel* for 10.0.z, *luminous*
  59 for 12.0.z, etc.) or *master*.  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 *master*. During this phase, all commits to *master* 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 *master* - it will make it into the next release candidate either way.
  65
  66 When ?
  67 ^^^^^^
  68
  69 After the first stable release candidate is published, i.e. after the
  70 x.1.0 tag is set in the release branch.
  71
  72 Branch merges
  73 ^^^^^^^^^^^^^
  74
  75 * The stable release branch is merged periodically into *master*.
  76 * The *master* branch is merged periodically into the stable release branch.
  77 * The *master* branch is merged into the stable release branch
  78   immediately after each x.1.z release candidate.
  79
  80 Stable release candidates (i.e. x.1.z) phase 2
  81 ----------------------------------------------
  82
  83 What ?
  84 ^^^^^^
  85
  86 * Bug fixes only
  87
  88 Where ?
  89 ^^^^^^^
  90
  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 *master*. 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".
  96
  97 When ?
  98 ^^^^^^
  99
 100 After Sage Weil announces that it is time for phase 2 to happen.
 101
 102 Branch merges
 103 ^^^^^^^^^^^^^
 104
 105 * The stable release branch is occasionally merged into master.
 106
 107 Stable releases (i.e. x.2.z)
 108 ----------------------------
 109
 110 What ?
 111 ^^^^^^
 112
 113 * Bug fixes
 114 * Features are sometime accepted
 115 * Commits should be cherry-picked from *master* when possible
 116 * Commits that are not cherry-picked from *master* must pertain to a bug unique to
 117   the stable release
 118 * See also the `backport HOWTO`_ document
 119
 120 .. _`backport HOWTO`:
 121   http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO#HOWTO
 122
 123 Where ?
 124 ^^^^^^^
 125
 126 The stable release branch (*hammer* for 0.94.x, *infernalis* for 9.2.x,
 127 etc.)
 128
 129 When ?
 130 ^^^^^^
 131
 132 After the stable release is published, i.e. after the "vx.2.0" tag is set in
 133 the release branch.
 134
 135 Branch merges
 136 ^^^^^^^^^^^^^
 137
 138 Never