Codecov Report

Attention: Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Please upload report for BASE (rel/4.0@40ff27c). Learn more about missing BASE report.

@@            Coverage Diff             @@
##             rel/4.0    #5974   +/-   ##
==========================================
  Coverage           ?   65.03%           
==========================================
  Files              ?      579           
  Lines              ?    32355           
  Branches           ?        0           
==========================================
  Hits               ?    21041           
  Misses             ?    11314           
  Partials           ?        0           

From discussion with @tannergooding, the version field can be used by tools to interpret Guid in certain ways.

https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-1

Version 1 for example is for UTC timestamps and network card MAC address encoding.
Version 3 is for values computed by MD5, etc etc.

If we want to embed our own version while following the RFC properly, we should use version 8, and reserve other bits for embedding our "own" version.

Note that in the past, I think we never followed the RFC accurately, as we just hashed and passed that to Guid constructor, meaning we are creating random versions, and none of the tools reading TRX today tries to interpret the version following the spec. So we were mostly okay, but still we violated the spec.

In addition, XxHash128 output is big endian, so it's best if we do new Guid(hash, bigEndian: true) instead of new Guid(hash).

Note that there is not much of a concern of us using extra bits for reserving our version with regards to collision probability, as it's still very unlikely to practically see collisions.

I think that summarizes our discussion @tannergooding (hopefully accurately/correctly).