Open Stack

Excerpts from Doug Hellmann's message of 2015-06-16 15:55:04 -0400:
> Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200:
> > Doug Hellmann wrote:
> > > [...]
> > > 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.
> > 
> > Your script missed 2015.1 tags for some reason...
> > 
> > I still think we should count the number of "integrated" releases
> > instead of the number of releases (basically considering pre-integration
> > releases as 0.x releases). That would give:
> > 
> > ceilometer 5.0.0
> > cinder 7.0.0
> > glance 11.0.0
> > heat 5.0.0
> > horizon 8.0.0
> > ironic 2.0.0
> > keystone 8.0.0
> > neutron* 7.0.0
> > nova 12.0.0
> > sahara 3.0.0
> > trove 4.0.0
> > 
> > We also traditionally "managed" the previously-incubated projects. That
> > would add the following to the mix:
> > 
> > barbican 1.0.0
> > designate 1.0.0
> > manila 1.0.0
> > zaqar 1.0.0
> > 
> 
> I have submitted patches to update all of these projects to the versions
> listed here.
> 
> See https://review.openstack.org/#/q/topic:semver-releases,n,z

Those patches were all failing because of semver rules enforced by
pbr.  The fix is to add a version tag for an earlier version (that
is, to make the 1.0.0 version change in setup.cfg work we need a
1.0.0a0 tag). I'm starting to push those tags today, and I will be
rechecking the setup.cfg updates as I do.

If you start seeing unexpected versions appear in your local sandbox,
the tags are why. I don't expect that to cause issues with any local
builds, but if you see problems start by rebuilding your tox
virtualenvs.

We did identify one potential issue with heat's reliance on its package
version for indicating deprecations and supported features. I'll be
waiting to make any of these changes to heat until I've had a chance to
confer with the core team about the best approach for ensuring the
version change won't cause issues.

Doug