[openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Doug Hellmann doug at doughellmann.com
Fri Jun 5 14:23:52 UTC 2015

Excerpts from Doug Hellmann's message of 2015-05-29 17:38:04 -0400:
> 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.

Thierry and I had a conversation about this today, and he has
convinced me that since project versions will diverge anyway, we
shouldn't start out using the same version for everyone. So instead
of picking 12 for all projects, we will look at how many releases
a project has had and add 1 to produce the next version. That will
spread out the version numbers now, and reduce the tendency for
consumers of the projects to assume that the version numbers match
up with the release cycles. We will work with the release liaisons and
PTLs to figure out the version numbers for projects as we get close to
the L1 milestone.


> 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

More information about the OpenStack-dev mailing list