Open Stack

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