You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JSON is not documented a requiring a uint32_t or even an integer, but it should presumably match
I'm assuming that "backwards compatible" is a typo, and "backwards incompatible" is meant ?
either way, it has a different meaning to "any major changes"
There'd also be some debugging value to being able to represent the actual human-readable version number, rather than just a "major changes" version. In practice, I think most layers just use "1".
This would require either that an arbitrary string is allowed, or a much larger type than uint32_t (especially for layers that increment the version number in every CI build). Currently, the description field could be (ab?)used for this
The text was updated successfully, but these errors were encountered:
An issue (number 2321) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2321 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
Concrete issues:
either way, it has a different meaning to "any major changes"
This would require either that an arbitrary string is allowed, or a much larger type than uint32_t (especially for layers that increment the version number in every CI build). Currently, the description field could be (ab?)used for this
The text was updated successfully, but these errors were encountered: