If you are new to OpenStack keep mixing up Liberty with Kilo and are unsure where Mitaka comes in, here’s a chart for you: http://docs.openstack.org/releases/
It tracks releases and their current status from the early days of Austin, Bexar and Cactus (all deprecated) to Kilo (current stable release, security-supported) and Liberty (under development.) The link from Liberty also pushes things forward with a detailed timetable for the release and leading up to the “M” Design Summit in Tokyo, when work starts in earnest on the next release, named Mitaka.
The last few steps leading to the Liberty release
“Historically, most service components followed a YEAR.N.z versioning scheme (for example, Kilo was 2015.1.0). Everything else followed a classic x.y.z semantic versioning scheme. With the big tent reform, we have more components, and a growing share of them opt to make intermediary releases and follow x.y.z versioning style,” Thierry Carrez, OpenStack Technical Committee chair and release management project team lead (PTL) told Superuser.
To simplify that, he says, starting with the Liberty development cycle it was decided to use x.y.z versioning for all OpenStack deliverables. So, for example, the Nova Liberty release won’t be 2015.2.0, but 12.0.0 (a number arbitrarily chosen since that is the 12th major release of Nova.)
“That’s all fine and coherent,” he adds, “but that makes it difficult to associate development cycle names with component versions.” Enter the chart as a way to clearly document which components and which versions are present in each development cycle, before we arrive at the end of the Liberty cycle. Carrez credits veteran developer and OpenStack community member Doug Hellmann for driving that effort within the release management team.
Carrez shared the new chart with the OpenStack Foundation team — and as one of those people who has occasionally bungled the name/release cycle, I ask him why it’s so hard for people to get their heads around.
“It is a lot of projects and a lot of names, so mapping cycle names to versions is actually non-trivial,” he says. “Having a clear website with reference information makes it easier for everyone. The website is dynamically built from data that is maintained in the Openstack/releases Git repository, so it will be automatically be kept up-to-date as we make future releases.”
- OpenStack Homebrew Club: Meet the sausage cloud - July 31, 2019
- Building a virtuous circle with open infrastructure: Inclusive, global, adaptable - July 30, 2019
- Using Istio’s Mixer for network request caching: What’s next - July 22, 2019