document header tagging conventions

[bashbaug]

Here is a PR that documents our header tagging conventions in the README FAQ. It describes both the existing tagging for the Vulkan SDK and a new date-based "CalVer" tag for other usages. We can expand this to other tagging conventions in the future if we choose to do so.

If this gets merged, and we decide to use date-based tags, I will create a date-based tag based on our agreed upon convention, which could be for example v2026.07.0 (or v2026.08.0 if it pushes into next month).

[oddhack]

FWIW Khronos long ago agreed to use ISO(*) 8601 (2026-08-01) date format in general. Tags are an outlier case since the date is imbedded and there's some history associated with them.

(*) It is nice for standards groups to use standards themselves. Personally I wish people would stop using local and often nonexistent or temporally incorrect timezone codes when sending out meeting announcements in favor of UTC, but I digress.

[bashbaug]

I think this proposal is mostly consistent with ISO 8601. The main difference is . vs. - as the separator. If we want to treat the tag as a traditional version, I think . makes sense, but I'm flexible.

AFAICT ISO 8601 also mandates a four-digit year YYYY and a zero-padded (and hence, unconditionally two-digit) month 0M, so this is all consistent.

I'm open to including the date in our tags also, but this could get awkward if we ever end up needing to tag twice on the same day. In this case, is the first tag e.g. v2026.08.03 and then the second tag is v2026.08.03.1? Or do we always include the "release", so the first tag on a day would be v2026.08.03.0? Both of these options would work, but they seem verbose to me.

We could also go coarser, and just include the year and the release, so initially v2026.0, followed by v2026.1, etc. It looks like SPIRV-Tools releases follow this convention, FWIW, though if this repo adopts a similar convention it could also generate confusion if users expect the SPIRV-Tools tags to match the SPIRV-Headers tags.