Open Stack

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