Notes: Microversions

Jump to bottom

Carolyn Van Slyck edited this page Nov 13, 2015 · 7 revisions

Nova switched to microversions instead of versioning the endpoint. Going forward it will always be /v2.1/

The api docs contain a mixed bag of what is in the latest microversion. Use the version history as a guide for now.

The SDK needs to support a few scenarios:

Single cloud user, has no idea what a microversion is and just wants to get the job done.
Multi-cloud user, found a microversion that has what they want and they are sticking to it.
Multi-cloud developer. Needs to know what is supported and easily fallback to other workarounds.

We want to make life easiest for 1 and 2, while not making 3's job impossible.

Each microversion is a different namespace, with all classes included, e.g. request/response objects, ComputeService, ComputeApiBuilder, etc.
User picks a namespace and they can use whatever they see.
Microversions are cumulative. 2.10 will include everything from 2.1-2.9 excluding deprecated items.
Provide a way to query the supported version range so #3 can react accordingly. I don't anticipate #3 making much use of the using directives and instead cherry-picking from whatever makes sense based on the supported range of the current connected provider.
Classes in each microversion use inheritance (as things are cumulative). Most verisons will have nothing different except a method or property, everything else comes through via inheritance. For anything that has been removed, override, mark with Obsolete and EditorBrowsable(EditorBrowsableState.Never) so a user won't see them. Implement it by throwing a NotSupportedException with the microversion # referenced so that if it is invoked via sneaky means (e.g. reflection, crazy casting etc) that they understand why it failed.