Differences in any of the Vulkan version numbers indicates a change to the API in some way, with each part of the version number indicating a different scope of changes.
A difference in patch version numbers indicates that some usually small part of the specification or header has been modified, typically to fix a bug, and may have an impact on the behavior of existing functionality. Differences in this version number should not affect either full compatibility or backwards compatibility between two versions, or add additional interfaces to the API.
A difference in minor version numbers indicates that some amount of new functionality has been added. This will usually include new interfaces in the header, and may also include behavior changes and bug fixes. Functionality may be deprecated in a minor revision, but will not be removed. When a new minor version is introduced, the patch version is reset to 0, and each minor revision maintains its own set of patch versions. Differences in this version should not affect backwards compatibility, but will affect full compatibility.
A difference in major version numbers indicates a large set of changes to the API, potentially including new functionality and header interfaces, behavioral changes, removal of deprecated features, modification or outright replacement of any feature, and is thus very likely to break any and all compatibility. Differences in this version will typically require significant modification to an application in order for it to function.
What does this mean for extensions? For example Swapchain
Dependencies
This extension is written against version 1.0 of the Vulkan API. This extension requires VK_KHR_surface.
Does this mean that this extension won't add any features in the future? For example if the Vulkan spec will bump its minor version to 1.1.0, is the spec allowed to add new functionality to existing extensions?
Can I assume that new functionality for existing extensions will only be released as a new extension?
Looking at VkExtensionProperties
specVersion is the version of this extension. It is an integer, incremented with backward compatible changes.
It would seem odd if extensions could be extended in future revisions because Vulkan uses the version format Major, Minor, Patch and extensions only use an integer. I would expect that extensions would use Minor, Patch if they would add functionality in future revisions.
1)
It does mean very little for extensions, because it is (unless otherwisely said) versioning scheme for the (core) Vulkan.
Currently, extension header is part of the core header, so extension change (requiring header change) would imply bump in the core patch version, when it is published in that header.
2)
Dependency mostly means you can't enable an extension unless you also enable the dependency. (It is bit under-specified. E.g. it is not clear to what degree just reusing structures/enums of other extension is a dependency. And what exactly "written against" implies. But NVM that...)
I think your implication is incorrect, but reasonable:
Adding new functionality should be allowed as long as it is backwards-compatible (actually irregardless of core Vulkan minor version). But I hope there would be some esthetical consideration made by the developer (adding alt commands and such to extension might get ugly).
Extension should be able to remain valid while Vulkan transitions into 1.1 (because it is supposed to be backwards-compatible).
Something else must happen for core Vulkan version 2. But I think nobody is bothered by that yet. At worst they can "cheat" and specify differently how extension versions are supposed to work. Or more probably just scrap all Vk1 extensions (because they would be implicitly incompatible with Vk2).
3)
It would be nice to have minor version, but it is not strictly necessary.
It does matter little whether you know if the desired functionality appeared in the X minor version or in the X (just integer) revision.
It would be overkill design considering most extensions are version 1 anyway.
The
specVersionis bit of a misnomer (possibly copy-paste error). In the rest of the spec it is called revision.