On 8/28/2015 10:35 AM, Joe Gordon wrote:
On Aug 28, 2015 6:49 AM, "Sean Dague" <s...@dague.net <mailto:s...@dague.net>> wrote: > > 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 Sounds like we need to update the docs for this. > 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 Considering how unclear these two points appear to be, are they clearly documented somewhere? So that as more projects embrace microversions, they don't end up having the same discussion.
Yar: https://review.openstack.org/#/c/218403/
> > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
-- Thanks, Matt Riedemann __________________________________________________________________________ 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
