Open Stack

This message is a summary of the notes from the “Release Versioning Servers” discussion held during the release management/QA/infrastructure meetup period on Friday morning at the summit, along with some commentary I thought of as I was typing them up. There is no etherpad for that session, but the notes we took were captured as a photo of the whiteboard, which you can see at http://doughellmann.com/2015/05/29/openstack-server-version-numbering.html

tl;dr: To simplify release management, especially for projects releasing more than one time per cycle, we would like projects currently using date-based versioning to move to semver. Existing projects following some form of semver should keep doing what they’re doing.


Moving away from date-based release numbers removes the confusion about what an update to a release occurring in the following year means. It also makes it easier for us to publish server releases through PyPI, if we choose to do that (it was discussed, but I don’t remember a firm agreement). The transition introduces some complications, but we think it is possible to handle them all.

As with our other semver projects, we will use pbr’s interpretation of the semver rules (http://docs.openstack.org/developer/pbr/semver.html) for minor updates and patch releases. I don’t believe we discussed whether to increment the major version during each cycle as we have been doing. Under the semver rules that would indicate incompatibility, and we may not want to signal that arbitrarily. We should discuss that further leading up to the M summit, when we start preparing for the *next* cycle.

Since kilo was release 11, I proposed we start with version 12.0.0 for everyone’s next release and proceed from there following semver rules. This will result in resetting the version numbers to values lower than they are currently (12 < 2015), but the distributions can prepend an epoch value to their version number to ensure upgrades work properly. It will also mean that project versions will drift apart over time, since some projects such as Ironic will start having more intermediate releases.

We will still use stable branches, and stable release versions will follow the same rules so it should always be clear what versions are upgrades of what previous releases.

The library projects should already be using semver. In some cases they aren’t, but we’ll be fixing that separately this cycle. Server projects already using semver-like rules should continue to follow their existing patterns, unless they want to adopt this new process, in which case the release team will be happy to help them set up whatever they need.

Please let me know if you think I missed any details, or misunderstood something as agreed to. Or, of course, if you weren’t there and see something wrong with the plan after looking at it now.

Doug