spirv: Vulkan SDK based versioning #225
Comments
|
@msiglreith Thanks! Blame KhronosGroup/SPIRV-Headers#199 for not being pinged about this release! I have sneakily been keeping this up to date in #226 - still needs one clippy/check fix, but it's already usable. |
As for basing our version on the SDK, we've intentionally not done that when restarting with the (Unless you were merely mentioning that SPIR-V is now following SDK versioning, and are solely requesting rspirv to update) |
|
The last part was mostly related to tying it closer to Vulkan as main consumer/driving force for SPIR-V modules, in case this is not desired. As the current version scheme is more general purpose (ie OpenCL). |
|
I personally don't really mind, just happy SPIRV-Headers finally starts tagging their commits after a massive period of silence. For (r)spirv we'll just keep following the semver we got going already, with the |
|
@msiglreith This issue is resolved now that we moved from Unfortunately the requested release of the first SDK regen in #226 hasn't made it into a release yet, but I'm not sure if this issue is just requesting a release anymore, or was only raising awareness about finally getting newer |
|
Right thanks, this was more about keeping the source more in-sync with the SPIRV changes given the SPIRV release cycle were very long |
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
The current SPIR-V version used is 1.5.4 which is almost 1 year old. With the latest Vulkan SDK, SPIR-V headers are tagged with the SDK version, which should update more regularly. This couples it more with the Vulkan version scheme tho.
Latest: https://github.com/KhronosGroup/SPIRV-Headers/releases/tag/sdk-1.2.198.0
The text was updated successfully, but these errors were encountered: