[openstack-dev] [sahara] summit wrap-up: backward compat

Michael McCune mimccune at redhat.com
Wed May 28 17:59:37 UTC 2014



----- Original Message -----
> > Open questions
> 
> 1. How should we handle addition of new functionality to the API,
> should we bump minor version and just add new endpoints?

I think we should not include the minor revision number in the url. Looking at some of the other projects (nova, keystone) it looks like the preference to make the version endpoint able to return information about the specific version implemented. I think going forward, if we choose to bump the minor version for small features we can just change what the version endpoint returns. Any client would then be able to decide if they can use newer features based on the version reported from the return value. If we maintain a consistent version api endpoint then I don't see an issue with increasing the minor version based on new features being added. But, I only endorse this if we decide to solidify the version endpoint (e.g. /v2, not /v2.1).

I realize this creates some confusion as we already have /v1 and /v1.1. I'm guessing we might subsume v1.1 at a point in time where we choose to deprecate.

> 2. For which period of time should we keep deprecated API and client for it?

Not sure what the standard for OpenStack project is, but I would imagine we keep the deprecated API version for one release to give users time to migrate.

> 3. How to publish all images and/or keep stability of building images
> for plugins?

This is a good question, I don't have a strong opinion at this time. My gut feeling is that we should maintain official images somewhere, but I realize this introduces more work in maintenance.

regards,
mike



More information about the OpenStack-dev mailing list