Yes, micro-versioning is most likely a better approach, and I’m a fan of using that to gain the benefits of V3 without changing for the sake of change. Ideally in a versioned API we should be versioning a smaller surface area than “THE WHOLE API” if at all possible. If we kept the old “version” around and deprecated it (keep it for 2 cycles, when it goes away the non-versioned call says “sorry, version unsupported”?, and it can continue to be versioned as needed) and continue to increment the versions as appropriate with changes, we will be holding true to our contract. The benefits of V3 can still be reaped, knowing where the API should move towards.
Don’t try and take on a giant task to make a “new API version” at once. We can maintain the contract and still progress the APIs forward. And to Sean’s comment that the V2 API hasn’t been as “stable in the traditional sense” in the past, I think we can forgive past issues since we now have the framework to show us when/if things end up being incompatible (and I agree with the fact that big-bang changes don’t work for large surface area projects). I still stand by my statement that we can’t (shouldn’t knowingly) break the contract, we also can’t assume people will move to V3 (if we launch it) in a reasonable timeframe if the new API doesn’t really justify a massive re-write. Maintaining 2, nearly identical, APIs is going to be problematic for both the developers and deployers. In my view (as a deployer, consumer, and developer) this means we should keep V2, and work on benefiting from the lessons learned in developing V3 while moving to correct the issues we have in a maintainable / friendly way (to developers, deployers, and consumers). — Morgan Fainberg Principal Software Engineer Core Developer, Keystone m...@metacloud.com On February 24, 2014 at 15:22:01, Sean Dague (s...@dague.net) wrote: On 02/24/2014 06:13 PM, Chris Friesen wrote: > On 02/24/2014 04:59 PM, Sean Dague wrote: > >> So, that begs a new approach. Because I think at this point even if we >> did put out Nova v3, there can never be a v4. It's too much, too big, >> and doesn't fit in the incremental nature of the project. > > Does it necessarily need to be that way though? Maybe we bump the > version number every time we make a non-backwards-compatible change, > even if it's just removing an API call that has been deprecated for a > while. So I'm not sure how this is different than the keep v2 and use microversioning suggestion that is already in this thread. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net - signature.asc, 493 bytes _______________________________________________ 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
