Header versioning for compatibility with other components (as opposed to SPIR-V versioning)

[kloczek]

KhronosGroup/SPIRV-Tools#3647

[johnkslang]

[Edit: The following were my thoughts on using tags as a way of getting SPIRV-Tools compatability.]

It would be far more successful to use top of master than to rely on a tag.

If we tag often, how do you know which tag to use? It is the same problem of how to know which commit to use.

Or, are you asking for a rule that the most recent tag here should always work with SPIRV-Tools?

I'm not against making a tag, but I think we need some ground rules about what it means and when to do it, which in practice would operate successfully more often than top of master would work, but I'm unclear what those would actually be.

Wouldn't it be better for SPIRV-Tools to say which commit they depend on in SPIRV-Headers? Don't they already do that with a dependency file?

[kloczek]

Why?
Why other KhronosGroup modules can be versioned and exactly that one not?
And or what is the problem with marking current master as new version?
Try to think that in SPIRV-Headers offers ConfigVersion.cmake cmake file is SPIRV-Headers iv this module version and as long as someone will be using that cmake macros and version will be not bumped it will create messy situation.

Using tagged versions allows you as well to have some changes commuted which are still needs to be synced with other projects without affecting everything around.
I'm trying only to tell that none of the projects publicly available are not relaying on what master and almost always is used what has been tagged/released.

PS> BTW: SPIRV-Headers should offer as well pkgconfig .pc file which will allow detect is SPIRV-Headers installed or now and in which one version. If you want I try submit PR with that.

[johnkslang]

This can be versioned too, I'm not saying no.

I'm asking that, if we do version, how will you know which version is correct to use?

To me, it seems the missing piece is knowing what the right one is, independent of whether it is a commit, a tag, or a more formal release.

I think SPIRV-Tools must already say which commit it depends on, and that could be used, and everything would work.

[kloczek]

The same way as in case of SPIRV-Tools:

$ pkgconf --modversion SPIRV-Tools
2020.3.1

All what needs to be done is add SPIRV-headers.pc to this package similar to that one which is in SPIRV-Tools

[johnkslang]

I added the tag 1.5.3.reservations1 to top of master, to satisfy the immediate request.

We need to discuss internally the way to communicate which SPIRV-Headers is matched/tested with which other components (and which would be correct more often than simply selecting a recent commit).