2016-02-16 19:53 GMT+08:00 Sean Dague <s...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
