Open Stack

If we support 2.x.y, when we bump 'x' is a problem. We didn't order the API
changes for now, the version of API change is just based on the order of
patch merge. For support 2.x.y, we need bump 'y' first for back-compatible
changes I guess.

As I remember, we said before, the new feature is the motivation of user
upgrade their client to support new version API, whatever the new version
is backward compatible or incompatible. So I guess the initial thinking we
hope user always upgrade their code than always stop at old version? If we
bump 'x' after a lot of 'y', will that lead to user always stop at 'x'
version? And the evolution of api will slow down.

Or we limit to each release cycle. In each release, we bump 'y' first, and
then bump 'x'. Even there isn't any back-incompatible change in the
release. We still bump 'x' when released. Then we can encourage user
upgrade their code. But I still think the back-incompatible API change will
be slow down in development, as it need always merged after back-compatible
API change patches.



2016-02-13 4:55 GMT+08:00 Andrew Laski <andrew at lascii.com>:

> Starting a new thread to continue a thought that came up in
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html
> .
> The Nova API microversion framework allows for backwards compatible and
> backwards incompatible changes but there is no way to programmatically
> distinguish the two. This means that as a user of the API I need to
> understand every change between the version I'm using now and a new
> version I would like to move to in case an intermediate version changes
> default behaviors or removes something I'm currently using.
>
> I would suggest that a more user friendly approach would be to
> distinguish the two types of changes. Perhaps something like 2.x.y where
> x is bumped for a backwards incompatible change and y is still
> monotonically increasing regardless of bumps to x. So if the current
> version is 2.2.7 a new backwards compatible change would bump to 2.2.8
> or a new backwards incompatible change would bump to 2.3.8. As a user
> this would allow me to fairly freely bump the version I'm consuming
> until x changes at which point I need to take more care in moving to a
> new version.
>
> Just wanted to throw the idea out to get some feedback. Or perhaps this
> was already discussed and dismissed when microversions were added and I
> just missed it.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160215/359e6cf8/attachment-0001.html>