On 02/16/2016 09:34 AM, Andrew Laski wrote:
>
>
>
> On Tue, Feb 16, 2016, at 07:54 AM, Alex Xu wrote:
>>
>>
>> 2016-02-16 19:53 GMT+08:00 Sean Dague <s...@dague.net
>> <mailto: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.
>
> Fair enough, I wasn't thinking a lot about moving between installations
> just that we've hidden information within one installation.
>
> Since any change except one that is backwards and forwards compatible is
> a breaking change for users of multiple clouds what is essentially being
> said is that we have a new API with every microversion. Given that I
> wonder if we shouldn't make a stronger statement that the API differs,
> as in why even have a 2. prefix which implies that 2.x has some relation
> to 2.x+1 when it doesn't.
That was in the original conversations, to make it a monotonically
increasing single number. It got shot down somewhere in the middle of it
all, and I can't remember why now.
> It was mentioned elsewhere in the thread that we have a hard time
> knowing what's going to end up being compatible or not before it's
> released. This seems like something we should be able to determine and
> indicate somehow, even just through docs, otherwise we're passing that
> burden on to users to determine for themselves.
>
> I very much like that microversions have enabled development to move
> forward on the API without the mess of extensions that we had
> previously. I fear that we have no real measurement of the cost of
> consuming the API under this new scheme. It's easy enough to think that
> users will just read the docs and carefully consider every version
> increment that they want to consume but when they've been on version 2.7
> for a while and a new thing comes out in 2.35 that they want they need
> to fully digest the implications of all 27 intervening versions purely
> through docs and with the understanding that literally almost anything
> about the semantics can have changed. So while I love the freedom that
> it provides to developers I think it would be useful to have a small set
> of constraints in place that helps users. Of course all of my ideas have
> been duds so far and perhaps that's because I'm imagining future
> scenarios that won't come to pass or that we don't care about. But
> something has me concerned and I can't quite get my finger on it.
I definitely understand that concern. And I also don't think we've
really come up with a good way of getting docs to users yet (which is
not hugely different than the extension problem before).
-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
