From: Loic Dachary Date: Fri, 8 May 2015 20:25:21 +0000 (+0200) Subject: doc: move the release cycle after the timeline X-Git-Tag: v9.0.2~205^2~1 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=09681342641e769559cc5dfef931d2fc84533960;p=ceph.git doc: move the release cycle after the timeline The timeline is a useful reference and the reader should not have to scroll down to see it. Move the release cycle after the timeline. Signed-off-by: Loic Dachary --- diff --git a/doc/releases.rst b/doc/releases.rst index d3c330612557..eddce43a0c70 100644 --- a/doc/releases.rst +++ b/doc/releases.rst @@ -1,59 +1,9 @@ -================ -Release timeline -================ +============= +Ceph Releases +============= -The development release cycle is two to four weeks long. Each cycle -freezes the master development branch and applies `integration and -upgrade tests `_ for the -duration of one cycle before it is released and the next release's -code is frozen for testing. Once released, there is no effort to -backport fixes; developer focus in on the next development release -which is usually only a few weeks away. - -There are three to four stable releases a year. Each stable release -will receive a name (e.g., `Firefly') and bug fix backports at least -until the next stable release is out. - -Every other stable releases is a LTS (Long Term Stable) and will -receive updates until two LTS are published. For instance Dumpling is -retired when Hammer is published, Firefly is retired when Jewel is -published etc. The rationale is that backports to a LTS (Dumpling for -instance) are expected to happen until the next LTS is published -(Firefly is the LTS following Dumpling), to fix bugs and possibly -backport important features. After the next LTS is published, there -backports are still expected to fix bugs with a focus on whatever can -prevent upgrades to the next LTS (in our example, fixes to Dumpling -were published after Firefly was released and until Hammer was -published, primarily to ensure Dumpling cluster can smoothly migrate -to Firefly). - -* LTS : until the next two LTS are published -* Stable release : until the next stable release is published -* Development / testing release : no backports - -For each stable release: - -* `Integration and upgrade tests - `_ are run on a regular basis - and `their results `_ analyzed by Ceph - developers. -* `Issues `_ - fixed in the development branch is scheduled to be backported to the - release. -* When an issue found in the release is `reported - `_ it will be - triaged by Ceph developers. -* The `stable releases and backport team `_ - publishes ``point releases`` including fixes that have been backported to the release. - -In the following, the life time of a LTS is calculated to be -approximately 18 months after the month of the first release. For -instance, Dumpling is published August 2013 and 18 months starting -September 2013 is February 2015, therefore by March 2015 Dumpling -should be retired. The lifetime of a release may vary because it -depend on how quickly the stable releases are published. For instance -although Dumpling theoritical retirement was March 2015, it was -extended to May 2015. +Timeline +-------- +----------------------------+-----------+-----------+-----------+-----------+-----------+ | |`Dumpling`_|`Emperor`_ |`Firefly`_ |`Giant`_ |`Hammer`_ | @@ -220,3 +170,59 @@ extended to May 2015. .. _0.67.1: ../release-notes#v0-67-1-dumpling .. _0.67: ../release-notes#v0-67-dumpling .. _Dumpling: ../release-notes#v0-67-dumpling + +Understanding the release cycle +------------------------------- + +The development release cycle is two to four weeks long. Each cycle +freezes the master development branch and applies `integration and +upgrade tests `_ for the +duration of one cycle before it is released and the next release's +code is frozen for testing. Once released, there is no effort to +backport fixes; developer focus in on the next development release +which is usually only a few weeks away. + +There are three to four stable releases a year. Each stable release +will receive a name (e.g., `Firefly') and bug fix backports at least +until the next stable release is out. + +Every other stable releases is a LTS (Long Term Stable) and will +receive updates until two LTS are published. For instance Dumpling is +retired when Hammer is published, Firefly is retired when Jewel is +published etc. The rationale is that backports to a LTS (Dumpling for +instance) are expected to happen until the next LTS is published +(Firefly is the LTS following Dumpling), to fix bugs and possibly +backport important features. After the next LTS is published, there +backports are still expected to fix bugs with a focus on whatever can +prevent upgrades to the next LTS (in our example, fixes to Dumpling +were published after Firefly was released and until Hammer was +published, primarily to ensure Dumpling cluster can smoothly migrate +to Firefly). + +* LTS : until the next two LTS are published +* Stable release : until the next stable release is published +* Development / testing release : no backports + +For each stable release: + +* `Integration and upgrade tests + `_ are run on a regular basis + and `their results `_ analyzed by Ceph + developers. +* `Issues `_ + fixed in the development branch is scheduled to be backported to the + release. +* When an issue found in the release is `reported + `_ it will be + triaged by Ceph developers. +* The `stable releases and backport team `_ + publishes ``point releases`` including fixes that have been backported to the release. + +In the timeline, the life time of a LTS is calculated to be +approximately 18 months after the month of the first release. For +instance, Dumpling is published August 2013 and 18 months starting +September 2013 is February 2015, therefore by March 2015 Dumpling +should be retired. The lifetime of a release may vary because it +depend on how quickly the stable releases are published. For instance +although Dumpling theoritical retirement was March 2015, it was +extended to May 2015.