Closed helsaawy closed 2 months ago
Hm.. moving this seems a bit scary, as there's quite some code consuming the old location. Moving it to go-winio reduces "some" of the issues, but effectively is just moving the goalposts a bit (with go-winio having less dependencies / somewhat more isolated).
Having this as a more isolated package could make sense, but if this were to move, would it make sense to either make this its own repository, or otherwise its own module, versioned separate from hcsshim and go-winio (which could mean it to stay in the old location, but as a separate module, and tagged separately.
If the code is to be moved, at least it would be good to preserve history (taking an approach similar as the steps done in https://github.com/moby/sys/pull/54)
also /cc @tianon (ISTR you were using it in various other places as well)
I use it a lot as the best reference I can find for build numbers and how they correspond to the "public" numbers like 1809 / "LTSC 2019" (I think https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/base-image-lifecycle is a more canonical location for that, but this Go file is way easier to read for this slice of information).
I've considered using it programmatically several times, but for all my use cases, the fact that it's just a fixed list of constants has been a blocker since it requires manually updating my code any time the list of constants changes (the use case I reconsider frequently is something like converting a particular os.version
value into a more human-friendly string like "Windows Server 2019" or something).
Move
osversion
package towinio
fromhcsshim
, so it can be imported separately. Additionally, dedicated types can be created for version components, and packaged version number can be removed fromVersion
struct without breaking APIs that currently rely on"hcssim/osversion"
.RtlGetVersion returns the windows OS version regardless of manifest, so that is preferred over GetVersion.