All great points. But, I just want us to read between the lines.
On 5/17/16 10:57 PM, Robert Collins wrote: > On 18 May 2016 at 00:54, Brian Rosmaita <brian.rosma...@rackspace.com> wrote: > >>> Couple of examples: >>> 1. switching from "is_public=true" to "visibility=public" >> >> This was a major version change in the Images API. The 'is_public' boolean >> is in the original Images v1 API, 'visibility' was introduced with the >> Images v2 API in the Folsom release. You just need an awareness of which >> version of the API you're talking to. > So I realise this is ancient history, but this is really a good Thank you for realizing that! Whatever keeps us from reopening this pandora's box again! > example of why Monty has been pushing on 'never break our APIs': API Sure, we need to consider when that was proposed and how OpenStack was operating before, who were the major stakeholders and why certain things needed to be changed. I am not arguing against your point, rather saying for sake of supporting an API that will remain maintainable long term. Have we considered all the things are important like security before saying that we need backward compatibility or are we willing to compromise on that?, I guess not. > breaks hurt users, major versions or not. Keeping the old attribute as > an alias to the new one would have avoided the user pain for a very > small amount of code. Again, we need to be careful about this, keep the compatibility when it makes sense and is possible. Having to maintain a hacky code is pretty bad idea I'd say. > > We are by definition an API - doesn't matter that its HTTP vs Python - > when we break compatibility, there's a very long tail of folk that > will have to spend time updating their code; 'Microversions' are a > good answer to this, as long as we never raise the minimum version we > support. glibc does a very similar thing with versioned symbols - and > they support things approximately indefinitely. All good points and we are going in that direction. Thanks for stating them explicitly. > > -Rob > > __________________________________________________________________________ > 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, Nikhil __________________________________________________________________________ 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
