Open Stack

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 <dtantsur at 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 <dtantsur at redhat.com
>> <mailto:dtantsur at 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-request at lists.openstack.org?subject:unsubscribe
>>         <
>> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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>
>> vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20150828/6adb87da/attachment.html>