I don't know if this is really a big problem. IMO, even with microversions you shouldn't be implementing things that aren't backwards compatible within the major version. I thought the benefit of microversions is to know if a given feature exists within the major version you are using. I would consider a breaking change to be a major version bump. If we only do a microversion bump for a backwards incompatible change then we are just using microversions as major versions.
-Alex On Fri, Aug 28, 2015 at 3:45 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 08/28/2015 09:34 AM, Valeriy Ponomaryov wrote: > >> Dmitriy, >> >> New tests, that cover new functionality already know which API version >> they require. So, even in testing, it is not needed. All other existing >> tests do not require API update. >> > > Yeah, but you can't be sure that your change does not break the world, > until you merge it and start updating tests. Probably it's not that > important for projects who have their integration tests in-tree though.. > > >> So, I raise hand for restricting "latest". >> >> On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur <dtant...@redhat.com >> <mailto:dtant...@redhat.com>> wrote: >> >> On 08/27/2015 09:38 PM, Ben Swartzlander wrote: >> >> Manila recently implemented microversions, copying the >> implementation >> from Nova. I really like the feature! However I noticed that >> it's legal >> for clients to transmit "latest" instead of a real version number. >> >> THIS IS A TERRIBLE IDEA! >> >> I recommend removing support for "latest" and forcing clients to >> request >> a specific version (or accept the default). >> >> >> I think "latest" is needed for integration testing. Otherwise you >> have to update your tests each time new version is introduced. >> >> >> >> Allowing clients to request the "latest" microversion guarantees >> undefined (and likely broken) behavior* in every situation where a >> client talks to a server that is newer than it. >> >> Every client can only understand past and present API >> implementation, >> not future implementations. Transmitting "latest" implies an >> assumption >> that the future is not so different from the present. This >> assumption >> about future behavior is precisely what we don't want clients to >> make, >> because it prevents forward progress. One of the main reasons >> microversions is a valuable feature is because it allows forward >> progress by letting us make major changes without breaking old >> clients. >> >> If clients are allowed to assume that nothing will change too >> much in >> the future (which is what asking for "latest" implies) then the >> server >> will be right back in the situation it was trying to get out of >> -- it >> can never change any API in a way that might break old clients. >> >> I can think of no situation where transmitting "latest" is >> better than >> transmitting the highest version that existed at the time the >> client was >> written. >> >> -Ben Swartzlander >> >> * Undefined/broken behavior unless the server restricts itself >> to never >> making any backward-compatiblity-breaking change of any kind. >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> < >> http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Kind Regards >> Valeriy Ponomaryov >> www.mirantis.com <http://www.mirantis.com> >> vponomar...@mirantis.com <mailto:vponomar...@mirantis.com> >> >> >> __________________________________________________________________________ >> 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 >
__________________________________________________________________________ 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