After reading through this thread as a whole, I¹d like to summarise my thoughts so far:
* I've noticed all these discussions revolve around existing people using the API, and seem to ignore that most new users of the API don¹t care how it used to work, and just want the full feature set without having to "opt-in². * While I was reading the thread, I realised how much I hate calling the client a client, I don¹t think we should think of it as a client (like a messaging or mail client) because it distances it from the actual API, I see it as a python API hook and as an API command line interface that you would build clients with. The level of abstraction should be just enough but not so much that it feels like a separate thing from the REST API. So if we solve the problem for the REST API then I think the python and command line should expose it in the same way. And I personally feel that explicit is the way forward, and if you don¹t specify a version we should error, provide no default, and no fall back, for those who don¹t want to use a specific version or are happy with whatever they are given, we should provide keywords that can be given instead of a version such as ³latest², ³given" or something to that effect. In this situation everyone knows what they are getting. - Sam On 29/07/2015 10:01, "Lucas Alvares Gomes" <lucasago...@gmail.com> wrote: >>> 1. yes >>> 2. no -- the client should default to the minimum supported version. >>>We got >>> that wrong previously, and that's what is hurting us now. >> >> So if we do this, simply shipping the code doesn't break anyone. Nobody >> has disagreed on this yet, best I can tell. >> > >We would still need a deprecation period here if we want to have the >client to default to the minimum supported version again. People using >the client may be relying on the features up to version 1.9 (which is >the pinned one right now). > >__________________________________________________________________________ >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