Discuss versioning

[rmarx]

Currently, we have only a single version field in qlog_version. This is somewhat inflexible, as it for example doesn't allow indicating updated versions of event definitions for individual protocols (say we have main schema version 2, but HTTP/3's events are already at 5, while you can also use 2, 3 and 4 with main schema 2).

I'm not entirely sure we need to go very fine-grained in this (e.g., indicating for each event which version it belongs to seems overkill), but a more advanced scheme than what we have currently is probably needed.

Original remark from @lpardue:

Do we also need independent versioning of the different schema? How does qlog evolve over the years? For example, say the main schema got published as 1.0, and then work commenced on 2.0. Can there be a QUIC qlog event definitions 1.1 (which is updated say to support QUIC v2) and a 2.1 (which is updated to support QUIC v2 and a new main schema format)?

[LPardue]

I think we might benefit from hearing from folks that have had to maintain versioned schema in the IETF. I doubt we need to reinvent the wheel here.

[rmarx]

This should be fixed by #415 (and partly by #417).

Newer versions of the events would have to register a new URI with IANA (e.g., :qlog:quic would be v1, :qlog:quic2026 would be v2, etc.) and then logging that in event_schemas should make it clear which version you're talking about (combined with qlog_version for the main schema)