On 11/22/2013 09:57 AM, Dolph Mathews wrote: > > On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez <thie...@openstack.org > <mailto:thie...@openstack.org>> wrote: > > Robert Collins wrote: > > I don't understand why branches would be needed here *if* the breaking > > changes don't impact any supported release of OpenStack. > > Right -- the trick is what does "supported" mean in that case. > > When the client libraries were first established as separate > deliverables, they came up with a blanket statement that the latest > version could always be used with *any* version of openstack you may > have. The idea being, if some public cloud was still stuck in pre-diablo > times, you could still use the same library to address both this public > cloud and the one which was 2 weeks behind Havana HEAD. > > > I'm curious about the historical circumstance of this requirement -- > were the services supported "master, minus two releases" at the time? > > We're not testing more than two stable releases against the latest > clients in CI today, so I find it odd that we still bother with this > claim, without demonstrating that it's true.
The design of this comes from an end-user perspective. If Alice wants to use a cloud, Bob, Alice should download the current python-glanceclient library, provide it with her credentials, and it should work, regardless of what version of OpenStack Bob's operator happens to be running. The reason for the above is that any other approach is a TERRIBLE end user experience. (As a person who currently is involved with running a scalable cloud application on two OpenStack clouds that are wildly different versions, I can tell you, needing to install different client library versions to talk to them would be madness. That's about outbound API versions though. That means that master *client must always be able to speak to every extant API version. This question is actually about python API consumption, and when we made the policy, we did discuss that were a breaking change to be made in the Python API, clearly the semver Major version should be bumped. Unfortunately for this conversation, we stopped with Brian Waldon's assertion of the major version bump and did not design a system to handle it. We do not currently have the machinery to handle it. At the very latest, we would need to design a modification to how zuul and devstack-gate construct collections of changesets. That said - we need to think about the questions raised above in terms of support of python API. But, more importantly, we should really think long and hard about breaking the python API, even with a major version bump, because no matter how you do it, it's disruptive to library consumers. > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > -Dolph > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev