On 08/28/2015 09:32 AM, Alex Meade wrote: > I don't know if this is really a big problem. IMO, even with > microversions you shouldn't be implementing things that aren't backwards > compatible within the major version. I thought the benefit of > microversions is to know if a given feature exists within the major > version you are using. I would consider a breaking change to be a major > version bump. If we only do a microversion bump for a backwards > incompatible change then we are just using microversions as major versions.
In the Nova case, Microversions aren't semver. They are content negotiation. Backwards incompatible only means something if time's arrow only flows in one direction. But when connecting to a bunch of random OpenStack clouds, there is no forced progression into the future. While each service is welcome to enforce more compatibility for the sake of their users, one should not assume that microversions are semver as a base case. I agree that 'latest' is basically only useful for testing. The python-novaclient code requires a microversion be specified on the API side, and on the CLI side negotiates to the highest version of the API that it understands which is supported on the server - https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23 -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev