GLSLANG_REVISION in revision.h reports previous tag name, which makes it appear out of date

[dneto0]

It says SPIRV99.1401 See https://github.com/KhronosGroup/glslang/blob/master/glslang/Include/revision.h#L5

I'm not relying on it, so it's not urgent for me.

[johnkslang]

If you execute glslangValidator -v you get this:

Glslang Version: SPIRV99.1401 11-Aug-2016
ESSL Version: OpenGL ES GLSL 3.00 glslang LunarG Khronos.SPIRV99.1401 11-Aug-2016
GLSL Version: 4.20 glslang LunarG Khronos.SPIRV99.1401 11-Aug-2016
SPIR-V Version 0x00010000, Revision 6
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

All these are available within the source as well. The "Glslang Version" part comes from the last tag name, which is indeed as stated, but it's not the place to get the SPIR-V version, as the next tag name could be something totally different.

[johnkslang]

FYI, you can see the sequence of names here: https://github.com/KhronosGroup/glslang/releases

Tags (release names) in general seem "off by one", because they get made to snapshot the previous one. So far, we are on SPIR-V 1.x, all backward compatible, and the previous one was SPIR-V 99.

Open to suggestions here.

High-order bit though is if you want the SPIR-V version, look at SPV_VERSION.

[dneto0]

Both KhronosGroup/SPIRV-Tools and google/shaderc use a mechanism that is primarily based on file contents rather than git metadata. The reason is that both are incorporated in AOSP but we don't have permission to set tags in those repos.

Each project has a CHANGES file in somewhat standard form. At build time a version string is constructed from (a) parsing that CHANGES file, and (b) results of "git describe" which itself incorporates tag and hash info.

But the most significant part is from the CHANGES file. It produces a version number of the form vyear.index and with an optional -dev suffix to indicate work in progress. For example, the following versions are ordered from oldest to newest:

v2016.0 v2016.1-dev v2016.1 v2016.2-dev v2016.2

The use of the "-dev" suffix is how we work around the off-by-one effect.

For example:

spirv-as --version SPIRV-Tools v2016.3-dev spirv-1.1-rev1-127-g8a5ce18 Target: SPIR-V 1.1

[johnkslang]

Note we've gone to a new tag Overload400-PrecQual, which avoids confusion about versions.

Edited to correct original backwards statement.

[johnkslang]

See also the detail in issue #478, where the desire is monotonically increasing tag numbers over time.

Trying to use descriptive names clearly isn't working well, due to the "off by one" problem.

[arcady-lunarg]

@dneto0 The versioning mechanism has been significantly overhauled since this issue was created. Is the current scheme okay for you, or are there still some issues with it?