2015-06-04 23:27 GMT+08:00 Lucas Alvares Gomes <lucasago...@gmail.com>:
> Hi Ruby,
>
> Thanks for starting this thread, just like you I've been always
> confused about when and when not bump the microversioning of the API.
>
> > Backwards compatible API adds with no user signaling is a fallacy
> > because it assumes the arrow of time flows only one way.
> >
> > If at version 1.5 you have a resource that is
> >
> > foo {
> > "bar": ...
> > }
> >
> > And then you decide you want to add another attribute
> >
> > foo {
> > "bar": ...
> > "baz": ...
> > }
> >
> > And you don't bump the version, you'll get a set of users that use a
> > cloud with baz, and incorrectly assume that version 1.5 of the API means
> > that baz will always be there. Except, there are lots of clouds out
> > there, including ones that might be at the code commit before it was
> > added. Because there are lots of deploys in the world, your users can
> > effectively go back in time.
> >
> > So now your API definition for version 1.5 is:
> >
> > "foo, may or may not contain baz, and there is no way of you knowing if
> > it will until you try. good luck."
> >
> > Which is pretty aweful.
> >
>
> Oh, that's a good point, I can see the value on that.
>
> Perhaps the guide should define bumping the micro version something
> along these words: "Whenever a change is made to the API which is
> visible to the client the micro version should be incremented" ?
>
Yes, I should put some words about why we should bump for back-compatible
changes.
>
> This is powerful because gives the clients a fine grained way to
> detect what are the API features available.
>
> Cheers,
> Lucas
>
> __________________________________________________________________________
> 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
>
__________________________________________________________________________
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
