chiprunner1995 / poshsemanticversion Goto Github PK

Use ETS to add Increment() script method to native SemanticVersion type.

It may be useful to support previous versions of the SemVer specification.
For example, the PowerShell gallery has basic support for adding SemVer 1.0.0 style prerelease labels to published scripts and modules.

Just as System.Version, and System.Management.Automation.SemanticVersion are immutable, so should this module's primary output type. This will also ease the transition to v5.0 classes and support for the v6.0 SemanticVersion type.

The current output objects are mutable, because they can be modified using the Increment() method. In order to work as an immutable object, Increment() should return a new object instead of changing the current object. Changing Increment() in this way would be considered a breaking change.

New-SemanticVersion with error if -InputObject is not a complete version number. This is because it validates the input before generating the SemanticVersion object. From a usability perspective, the commands should try and work with incomplete version numbers.

Because System.Version does not support pre-release identifiers, converting a pre-release SemVer to System.Version should result in the previous normal (non-pre-release) version, not the next normal version.

• Increment semver object to next version based on semver v2.0.0 specification.
• Add parameters for name of the semver component (major, minor, patch, pre-release, build)
• Add parameters for change-type keywords (feature, fix, breaking, chore, etc.)

• Convert from string to semver object.
• The conversion should be done in the function or static class function, not built into the semver object.

Right now, Step-SemanticVersion only processes the last pipeline object it receives. It should process all pipeline objects.

I tried import the module after installation on a Linux environment via an Azure build pipeline task and I received an exception with the following error 'Remove-Variable: Cannot find a variable with the name 'key'.

After narrowing it down I figured the error was coming from the last line in the module (.psm1) file.
Remove-Variable privateScriptFiles, publicScriptFiles, file, localizedMessages, key

It appears that since on line 106 of the same, the Import-LocalizedData command is invoked with an ErrorAction parameter value of 'SilentlyContinue',
Import-LocalizedData -BindingVariable localizedMessages -Filename messages -ErrorAction SilentlyContinue
If it turns out that there are no localized data present in the environment, then the 'key' variable used in the loop on line 108 is never created. As a result, when Remove-Variable is invoked, it fails to find the 'key' variable then throws an exception.
foreach ($key in $localizedMessages.Keys) { $messages[$key] = $localizedMessages[$key] }

Add comparison-operator switches (-gt, -lt; like the Where-Object cmdlet uses) to compare semantic versions. When these switches are used, a boolean value should be returned.

Use a .Net class so semver objects can be compared for precedence using IComparable interface. This will make it easier to compare objects using standard methods.

• Convert an object to a string, then to a .Net System Version. Convert from SemVer to System.Version.
• The conversion should be done in the function or static class function, not built into the semver object.

public / private directories are missing from the release.

When software is updated, it is given a new version number. Should the semver object be the same?