Add some form of versioning to the header.

[Kangz]

Even with no-breaking changes planned to ever happen again, the header will keep growing as features are added. There should be a monotonic version number of sorts that users can rely on to refer to specific versions of the header.

[bkaradzic]

It would be really nice to get this version at least in form of Hungarian style date...

How useful that might be you can see in your own headers that test __STDC_VERSION__:

webgpu-headers/webgpu.h

Line 80 in b5ff182

# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L

Anyone supporting WebGPU on native really needs this:
https://x.com/ocornut/status/2094360921174847994

[cwfitzgerald]

I love when people talk about projects behind their metaphorical back instead of letting them know directly...

[cwfitzgerald]

Thanks for bringing it to our attention

[ocornut]

(PS: i'm the person screenshotted, apologies for rant.)
I have reached out to Corentin today to ask about this, and seeing those threads I realized we probably have had this conversation back then already, as he kindly opened issues in various places for this.

[ocornut]

I'm personally a very casual user of webgpu/wgpu APIs, my only interaction with the API has been to try supporting those backends. Merely navigating the different options has been uneasy (partly because it has evolved a lot in past years, partly because DAWN is such a large thing to use and doesn't ship binaries- I later realized that wgpu-native was easier to work with and kindly shipped binaries, thanks). So I come from an angle where I barely know who does what, what are the acronyms for, nor why there are varying alternatives.

It would just feels generally nice if the header files could spell out a few extra details to aid general orientation: this is project XX, version XX, date XX.

I do also realize that dear imgui situation may be fairly unique: i am shipping a library that's aimed to work in a maximum of projects and not restrict users in their choice, so I can't just pin to some commit or version. Ideally I would want to work a maximum of API changes (aka support old API versions etc.) but for a fast evolving API like here maybe it's not so reasonable. Perhaps there aren't many projects having to deal with that constraint and I am the only person currently affected by lack of versioning, but I suppose it never hurts to version headers assuming WebGPU API are going to live for a decade+ and evolve accordingly.