3:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Note that the new versioning proposal starts to land in projects, so
you may need a series of fixes to add epochs to your server packages.
F.e. see neutron series in delorean:
https://review.gerrithub.io/#/q/Ie7f47fb6f13487ddb6ae4d75184d9d86c0ce4a8
4
- -------- Forwarded Message --------
Subject: Re: [openstack-dev] [all][release] summit session summary:
Release Versioning for Server Applications
Date: Wed, 17 Jun 2015 11:44:22 -0400
From: Doug Hellmann <doug(a)doughellmann.com>
Reply-To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev(a)lists.openstack.org>
To: openstack-dev <openstack-dev(a)lists.openstack.org>
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
________________________________________________________________________
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscri
be
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVgoVjAAoJEC5aWaUY1u57yQUH/jS5IyonTXKFJy1ujzm2c6Ql
9dhc/t6FOOqZvFKCkqep8B/MybgQo6YHrY2JolLM+tvfobjE3qpmS5QrZRXWp+60
gYuhXu2KDRZK+tsAIWsEPSFabgrgLlQNP+280pkigUbIEiGNc68MlG9xExy68sun
Wt9lcQF/Hy16lxSgWz95k+JekjC4t2m27NtVXV7x/bbmmfve3PNQTcNA6WmD0nZ3
QlVW/xlQXZoZ4YIzFkNmStKTudTWJqdmrqHBBjmppXvKv8ef6Yg9F19A8sQtnjjl
jmwCrx4vZg3nc1/AbF4rq9uXMiRJ/5dFp+C9S+hs7XwsfaP+myuXbD/uHtLtzAg=
=+Qbr
-----END PGP SIGNATURE-----