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. Doug > > 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
