[openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

Alex Xu soulxu at gmail.com
Tue Feb 16 12:54:11 UTC 2016


2016-02-16 19:53 GMT+08:00 Sean Dague <sean at dague.net>:

> On 02/12/2016 03:55 PM, Andrew Laski wrote:
> > 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.
>
> Please no.
>
> We specifically stated many times that microversions aren't semver. Each
> version is just that.
>
> Semver only makes sense when you are always talking to one installation,
> and the version numbers can only increase. When your code retargets to
> multiple installations version numbers can very easily go backwards. So
> unless a change in compatible forward and backwards, it's a breaking
> change for someone.
>

indeed, learned this point.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20160216/764bdccc/attachment.html>


More information about the OpenStack-dev mailing list