Excerpts from Doug Hellmann's message of 2015-06-05 10:23:52 -0400: > 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.
I put together a little script [1] to try to count the previous releases for projects, to use that as the basis for their first SemVer-based version number. I pasted the output into an etherpad [2] and started making notes about proposed release numbers at the top. For now, I'm only working with the projects that have been managed by the release team (have the "release:managed" tag in the governance repository), but it should be easy enough for other projects to use the same idea to pick a version number. I still need to chat with Kyle about some of the neutron spin-out projects, since their repositories have the old neutron tags but I don't think it's appropriate to use the same version number as neutron for newer projects. Here's the proposed list, let me know if you spot any surprises: ceilometer 5.0.0 cinder 6.0.0 glance 8.0.0 heat 5.0.0 horizon 9.0.0 ironic 3.0.0 keystone 8.0.0 neutron 8.0.0 neutron-fwaas neutron-lbaas neutron-vpnaas nova 12.0.0 sahara 3.0.0 trove 4.0.0 Doug [1] https://review.openstack.org/191228 [2] https://etherpad.openstack.org/p/liberty-initial-semver-values __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
