On 03/03/2014 12:32 PM, Russell Bryant wrote: > There has been quite a bit of discussion about the future of the v3 API > recently.
<snip> :-) Since this proposal was posted, it is clear that there is not much support for it, much less consensus. That's progress because it now seems clear to me that the path proposed (keep only v2) isn't the right answer. Let's reflect a bit on some of the other progress that I think has been made: 1) Greater understanding and documentation of the v3 API effort It has led to a larger group of people taking a much closer look at what has been done with the v3 API so far. That has widened the net for feedback on what else should be done before we could call it done. Chris has put together an excellent page with the most comprehensive overview of the v3 API effort that I've seen. I think this is very helpful: http://ozlabs.org/~cyeoh/V3_API.html 2) Expansion on ideas to ease long term support of APIs Thinking through this has led to a lot of deep thought about what changes we can make to support an API for a longer period of time. These are all ideas that can be applied to v3: - minor-versions for the core API and what changes would be considered acceptable under that scheme - how we can make significant changes that normally are not backwards compatible optional so that clients can declare support for them, easing the possible future need for another major API revision. 3) New ideas to ease keeping both v2 and v3 There has been some excellent input from those that have been working on the v3 API with some new ideas for how we can lessen the burden of keeping both APIs long term. I'm personally especially interested in the "v2.1" approach where v2 turns into code that transforms requests and responses to/from v3 format. More on that here: http://ozlabs.org/~cyeoh/V3_API.html#v2_v3_dual_maintenance What I'd like to do next is work through a new proposal that includes keeping both v2 and v3, but with a new added focus of minimizing the cost. This should include a path away from the dual code bases and to something like the "v2.1" proposal. Thank you all for your participation on this topic. It has been quite controversial, but the API we expose to our users is a really big deal. I'm feeling more and more confident that we're coming through this with a much better understanding of the problem space overall, as well as a better plan going forward than we had a few weeks ago. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev