Add a versionable DSC Resource interface with default implementation

[michaeltlombardi]

As an engineer developing and maintaining DSC Resources, I want to be able to inherit my implementation of a versionable DSC Resource from a known implementation, overwriting defaults with my own custom handling only if needed. Having a defined interface would also help with developing versionable DSC Resources, providing parse-time feedback on the implementation.

Versionable resources are a commonly required pattern for any implementation of a package resource, but also for compatibility verification. Without a standard adoptable pattern, implementations vary on whether they support version ranges fully, partially, or not at all.

Examples

• The Nuget DSC Resources don't use version ranges, but they could more easily do so with this model (functionally they only use RequiredVersion).
• cChoco/cChocoPackageInstall specifies Version and MinimumVersion as mutually exclusive properties, but not MaximumVersion.
• cDscDocker/DockerDSC functionally only supports RequiredVersion.
• xMySql/xMySqlServer functionally only supports RequiredVersion (and has not yet implemented set functionality for install/uninstall/update)
• xFirefox functionally only supports RequiredVersion.
• UnitySetup/xUnitySetupInstance functionally only supports RequiredVersion but allows multiple versions side-by-side.
• PackageManagement supports this model fully with RequiredVersion, MinimumVersion, and MaximumVersion (though with custom implementation in a function-based definition).
• ArcGIS/ArcGISInstall functionally only supports RequiredVersion.
• cIBMInstallationManager functionally only supports RequiredVersion.
• cIMBWebSphereAppServer functionally only supports RequiredVersion.
• PowerShellGetv2/PSModule supports this model fully with RequiredVersion, MinimumVersion, and MaximumVersion (though with custom implementation in a function-based definition).
• DSCR_Firefox/cFirefox functionally only supports RequiredVersion.
• DSCR_PythonPackage/pip functionally only supports RequiredVersion.
• PostgreSqlDsc/PostgreSqlInstall functionally only supports RequiredVersion.
• CondaDSC/CondaPackageInstaller functionally only supports RequiredVersion.

Proposal

Following on the proposals in #81, #82, and #85, I propose the creation of an IVersionableDscResource.

At a minimum, this interface should require:

• A TestVersion method, which takes a hash table (or class instance) as input and returns a Boolean
• The properties RequiredVersion, MinimumVersion, and MaximumVersion (as System.Version), with RequiredVersion as a normal property and MinimumVersion and MaximumVersion as parameters/write-only (Add a Write-Only / Parameter Attribute for the DscProperty attribute #76).

With default implementations, IVersionableDscResource could:

• Inherit from the IEnsurableDscResource interface (Add a default implementation of a DSC Resource #82)
• Have the default implementation of TestVersion:
  1. Check if the RequiredVersion, MinimumVersion, and MaximumVersion properties on the instance are $null, returning $true if all of them are
  2. If the RequiredVersion property on the instance is not $null, return the result of comparing it to the value of the RequiredVersion key in the input
  3. Check that the RequiredVersion in the input is within the boundaries set by the MinimumVersion and MaximumVersion properties of the instance, returning $true if it is and otherwise $false.
• Redefine the default implementation of Test as in Add an ensurable DSC Resource interface with default implementation #85, but call TestVersion after TestEnsurableState and before comparing the remaining values directly, returning $false if any check fails and $true if they all pass.

Addendum

This proposal covers an interface for a DSC Resource that expects only one version of the package/software on the system. Further thought (possibly an additional interface) should be given to supporting side-by-side versionable resources.