Hello

I'm using PsIni 1.2.0 in my own module. Inside of my module, I'm calling Set-IniContent.
In my manifest I declare:

    RequiredModules        = @(
        @{
            ModuleName    = 'PsIni'; 
            ModuleVersion = '1.2.0'; 
        }
    )

In Version 1.2.0 the parameter NameValuePairs of Set-IniContent accepts a string. In Version 1.2.0.38 and later, NameValuePairs requires a hashtable. This is a breaking change of the public module api. Something that I not expect when only the revision/build-number changes. A breaking change should lead in to a new major version number (PSIni 2.0.0.0).

To put ModuleVersion = '1.2.0.0' in my module manifest does not work, because such a version number can not be found by PowerShell:

Import-Module : The required module 'PsIni' is not loaded. Load the module or remove the module from 'RequiredModules' in the file [...]

When I use ModuleVersion = '1.2.0' in the manifest, PowerShell may import version 1.2.0, 1.2.0.38 or 1.2.0.39 of PsIni (depending on what version is installed on the machine), because all of them are matching with 1.2.0. Not all systems where my module is used are under my control, I can't simply update all systems to PSini 1.2.0.39.

Now I have to do something like this:

# Note: PSIni 1.2.0 has the version 1.2.0.-1
if ((Get-Module -Name PsIni | Select-Object -ExpandProperty Version).Revision -le 0){
    # Do the call in 1.2.0 style
} else {
    # Do the call in >=1.2.0.38 style
}

This is very uncool, but it's a workaround. So it's not a big deal, but it would be nice when:

(based on Semantic Versioning 2.0.0)

• Release Version 1.2.0.40 with the old public api
• Then release 2.0.0.0 with the new public api

I then can put ModuleVersion = '1.2.0.40' or ModuleVersion = '2.0.0' in the manifest to force the sys admins to update to a specific version of PsIni (because the import of my module will fail). On this way, I can be sure which api I can expect.

Best regards
Elia