On 02/24/2014 05:17 PM, Sean Dague 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.
It differs in that it allows the user to determine whether the changes
are forwards or backwards compatible. For instance, you might use an
API version that looks like {major}.{minor}.{bugfix} with the following
rules:
A new bugfix release is both forwards and backwards compatible.
A new minor release is backwards compatible. So code written against
version x.y will work with version x.y+n. New minor releases would
generally add functionality.
A new major release is not necessarily backwards compatible. Code
written against version x may not work with version x+1. New major
releases remove or change functionality.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
