Open Stack

On 8/28/2015 10:35 AM, Joe Gordon wrote:
>
> On Aug 28, 2015 6:49 AM, "Sean Dague" <sean at dague.net
> <mailto:sean at 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 

Thanks,

Matt Riedemann