[openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

Sean Dague sean at dague.net
Tue Feb 16 11:53:27 UTC 2016

On 02/12/2016 03:55 PM, Andrew Laski wrote:
> Starting a new thread to continue a thought that came up in
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html.
> The Nova API microversion framework allows for backwards compatible and
> backwards incompatible changes but there is no way to programmatically
> distinguish the two. This means that as a user of the API I need to
> understand every change between the version I'm using now and a new
> version I would like to move to in case an intermediate version changes
> default behaviors or removes something I'm currently using.
> I would suggest that a more user friendly approach would be to
> distinguish the two types of changes. Perhaps something like 2.x.y where
> x is bumped for a backwards incompatible change and y is still
> monotonically increasing regardless of bumps to x. So if the current
> version is 2.2.7 a new backwards compatible change would bump to 2.2.8
> or a new backwards incompatible change would bump to 2.3.8. As a user
> this would allow me to fairly freely bump the version I'm consuming
> until x changes at which point I need to take more care in moving to a
> new version.
> Just wanted to throw the idea out to get some feedback. Or perhaps this
> was already discussed and dismissed when microversions were added and I
> just missed it.

Please no.

We specifically stated many times that microversions aren't semver. Each
version is just that.

Semver only makes sense when you are always talking to one installation,
and the version numbers can only increase. When your code retargets to
multiple installations version numbers can very easily go backwards. So
unless a change in compatible forward and backwards, it's a breaking
change for someone.


Sean Dague

More information about the OpenStack-dev mailing list