I thought it could help with some software that is expecting windows 10,
1. It's not clear what software expecting windows 10 will actually benefit from it. A driver can fetch the version number via `RtlGetVersion` or `PsGetVersion`. A user-mode application can fetch the version number via `GetVersionEx`, `VerifyVersionInfo`, or `RtlGetVersion`.
2. Most importantly, it's not clear that the number of applications that will benefit from the change is _greater_ than the number of applications that will break because of the change. Let's assume that some applications _do_ use the file version of `ntoskrnl.exe` (via `GetFileVersionInfo` or similar). If the application determines that the Windows version is 10, and expects Windows 10 APIs that Wine has no implementation for, it will fail. Moreover, some applications will expect a version _older than_ Windows 10, and fail if the criteria are not satisfied.
and ntoskrnl.exe is still updated with every windows release, so I think it's a good idea to update the version number
If we want to match file version numbers from Windows, then we'll need another method for that since _every_ Windows quality update that involves the kernel will get the version bump.
**after** the code freeze so we can catch regressions before we release a stable version of wine.
Right. I think you've explained _how_ to catch regressions, but you'll have to state a convincing _why_.
this will probably be the last time it needs updating since microsoft probably won't make a windows NT 11.
I'm not sure what you're referring to as "windows NT 11." Windows 11, which was released October 2022, starts with the internal version number 10.0.22000, and it's indeed unlikely that Microsoft will bump the major component of the internal version from 10. This means that applications will read the build number instead. If I understood your comment correctly, you're saying that we'll have to bump the version number every time Windows has an update.