Microsoft/OSInfo: Support minimum version assertion (>= comparison)

[denelon]

Summary of the new feature / enhancement

The Microsoft/OSInfo resource currently performs exact string matching on the version property. This means asserting version: "10.0.22621" fails on a machine running 10.0.26614 — even though the machine exceeds the minimum requirement.

For configuration authors using Microsoft/OSInfo in assertions (e.g., "this config requires Windows 11 22H2 or later"), there's no way to express a minimum version constraint.

Observed behavior

dsc resource test -r Microsoft/OSInfo --input '{"family": "Windows", "version": "10.0.22621"}'

On a machine running 10.0.26614:

inDesiredState: false
differingProperties:
- version

Expected behavior

A way to specify that version should be treated as a minimum (>=) rather than an exact match. For example:

- name: assert_min_os
  type: Microsoft/OSInfo
  properties:
    family: Windows
    minVersion: "10.0.22621"

Or alternatively, support a comparison operator on the version property:

  properties:
    version:
      minimum: "10.0.22621"

Use case

WinGet Configuration files that need to assert a minimum OS version before applying resources (e.g., Dev Drive requires 22H2+, certain Windows Settings resources require specific builds). The Microsoft.Windows.Developer/OsVersion resource in WinGet DSC v2 supported MinVersion for this purpose — the native Microsoft/OSInfo resource would be the faster v3 equivalent if it supported minimum version comparison.

Additional context

• Microsoft/OSInfo capabilities are get + export (read-only, no set) — ideal for assertions
• It's a native Rust binary so it's extremely fast compared to PowerShell-based alternatives
• Semantic version comparison (or at minimum numeric dotted-version comparison) would make this resource the canonical way to gate configs by OS version
• Related: Assertion section in config doc #1421 (assertion section in config docs)

[michaeltlombardi]

I'm not sure how easy this will actually be across operating systems, particularly Linux distributions - we expose the version field as a simple string, but the underlying library uses an enum that distinguishes between variants:

pub enum Version {
    Unknown,
    Semantic(u64, u64, u64),
    Rolling(Option<String>),
    Custom(String),
}

I looked into the source code and found that the Windows implementation does always seem to return a semantic version, but that's not true on Linux (where releases can be numbered, date based, rolling, and so on) or macOS (where versions may be semantic or define only 2 version segments).

To provide this functionality, I think we would need to do something like:

1. Add a write-only field called semverRequirement that takes a DSC semantic version requirement, like ^1.2.3 or >=1.2.3, <1.5. This field is only used in the test operation.

2. Implement the test operation for the resource. Currently it uses synthetic testing through the DSC engine. It would be fairly low-effort to implement because it's an equivalency check for defined fields plus the version range check.

3. When a user defines semverRequirement, the test operation indicates that the resource is in the desired state only when:

   1. The version for the operating system is a semantic version.
   2. The version for the operating system matches the specified semantic version.

   Otherwise, the test result indicates that the resource isn't in the desired state because the version field is invalid for the instance.

An additional wrinkle here is that the semantic version requirement DSC uses is defined in the dsc-lib crate which depends on the dsc-lib-osinfo crate. This might require us to move the semantic version wrappers from dsc-lib to dsc-lib-semver to avoid a cyclical dependency.