Closed EliaSaSe closed 6 years ago
You are absolutely right. All >1.2.0 versions break 1.2.0.
I am sorry I missed that.
I will consider your suggestion.
Hello lipkau
Thank you for consider that. I don't need a "immediately fix" for this issue. It's enough when the next version of PSIni uses a distinctable version number. Until than, I will use my workaround.
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:In Version 1.2.0 the parameter
NameValuePairs
ofSet-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: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:
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)
I then can put
ModuleVersion = '1.2.0.40'
orModuleVersion = '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