Fix UUID for Darwin hosts #103
Conversation
- Addresses rs#100 based on fix suggested by @rpendleton - Adds multi-platform matrix run strategy to actions - Adds .gitignore file
|
Should be noted that I do not have a Darwin machine handy to test this on, thus I'm relying on gha runners :D |
|
Thanks for the PR. Could you please check the failing tests? |
|
Sorry for the slow response! Bumped to go1.16, which seems to be the oldest version with an available darwin arm64 build. |
|
Thanks. It is still failing due to some wrong build tags apparently. |
|
@rs Reverted that line back to the way it was. I'm used to the go1.17+ build tags, it seems :) |
|
Damn there is now a lint issue on windows. Do you mind applying the recommendation to make it pass? Thanks! |
- Explicitly ignoring defer in registry key closure - Using syscall.UTF16PtrFromString in lieu of deprecated StringToUTF16Ptr func
|
@rs Sorry again for the delay! Windows lint issues addressed :) |
|
@rs Sorry to bug you, but I believe the last of the issues have been adressed :) |
|
A thought: does this constitute a major version release, given the change in id generation? Presumably 3rd party impls will also have to update. |
|
There is no change of API or anything non-backward compatible, so it should remain a minor. Do I miss something? |
|
A key value source is different for Darwin now, no? I don't have a Darwin host to compare & contrast, unfortunately... Edit: ah, but we don't actually care, do we. Its uniqueness and stability is important, not the source. |
|
How is that affecting compatibility? |
|
If they generate a key on the same host using a lib with the previous mechanism, it will not match a value created with this change. |
|
What do you mean by "match"? The lib is meant to generate unique ids, two values generated by the lib should never match regardless of the lib version :) |
|
Ah, but the individual components are comparable, too, no? |
|
There is no guarantee the machine id would stay stable across versions. |
|
Fair enough 😄 |
kern.uuidis misinterpreted as a machine ID when it's actually a kernel version identifier #100 based on fix suggested by @rpendleton