Ceph Releases¶

Timeline¶

	Dumpling LTS	Emperor Stable	Firefly LTS	Giant Stable	Hammer LTS	Infernalis Stable
First release	August 2013	November 2013	May 2014	October 2014	April 2015	November 2015
Estimated retirement	March 2015		January 2016		November 2016	June 2016
Actual retirement	May 2015	May 2014	December 2015	April 2015

	Development Testing	Dumpling LTS	Emperor Stable	Firefly LTS	Giant Stable	Hammer LTS	Infernalis Stable
April 2016	10.1.2
April 2016	10.1.1
March 2016	10.1.0
March 2016	10.0.5
February 2016	10.0.3					0.94.6	9.2.1
January 2016	10.0.2
December 2015	10.0.1
November 2015	10.0.0			0.80.11			9.2.0
October 2015	9.1.0					0.94.5
October 2015						0.94.4
August 2015	9.0.3					0.94.3
July 2015	9.0.2			0.80.10
June 2015	9.0.1					0.94.2
May 2015	9.0.0
April 2015					0.87.2	0.94.1
April 2015						0.94
March 2015				0.80.9
February 2015	0.93				0.87.1
February 2015	0.92
January 2015	0.91			0.80.8
December 2014	0.90
December 2014	0.89
November 2014	0.88
October 2014	0.86			0.80.7	0.87
October 2014				0.80.6
September 2014	0.85	0.67.11
August 2014	0.84	0.67.10
July 2014	0.83			0.80.5
				0.80.4
				0.80.3
				0.80.2
June 2014	0.82
June 2014	0.81
May 2014		0.67.9		0.80.1
May 2014		0.67.8		0.80
April 2014	0.79
March 2014	0.78
February 2014	0.77	0.67.7
February 2014		0.67.6
January 2014	0.76
January 2014	0.75
December 2013	0.74	0.67.5	0.72.2
December 2013	0.73
November 2013			0.72.1
November 2013			0.72
October 2013	0.71	0.67.4
October 2013	0.70
September 2013	0.69
September 2013	0.68	0.67.3
August 2013		0.67.2
		0.67.1
		0.67

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., ‘Jewel’) 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 (Firefly for instance) are expected to happen until the next LTS is published (Jewel is the LTS following Hammer), to fix bugs and possibly backport important features. After the next LTS is published, 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).

Long Term Stable : 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 (master) are scheduled to be backported.
When an issue found in the stable release is reported, it is triaged by Ceph developers.
The stable releases and backport team publishes point releases including fixes that have been backported to the stable 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.

Release numbers conventions¶

The first Ceph release back in Jan of 2008 was 0.1. That made sense at the time. The versioning scheme did not change until April 2015, when 0.94.1 (the first Hammer point release) was published. To avoid reaching 0.99 (and 0.100 or 1.00?) we have a new strategy.

x.0.z - development releases (for early testers and the brave at heart)
x.1.z - release candidates (for test clusters, brave users)
x.2.z - stable/bugfix releases (for users)

x will start at 9 for Infernalis (I is the 9th letter), making our first development release of the 9th release cycle 9.0.0. Subsequent development releases will be 9.0.1, 9.0.2, etc.

After a couple months we’ll have a 9.1.0 (and maybe 9.1.1) release candidate.

A few weeks after that we’ll have the Infernalis release 9.2.0, followed by stable bug fix updates 9.2.1, 9.2.2, etc., and then begin work on the Jewel (10.y.z) release.