Non-Prerelease Modules do not install over Prerelease versions without -force

[smurawski]

The new prerelease support allows for prerelease naming of the package, but that doesn't reflect at all on PowerShell's versioning.

If I install module foo with a version of 2.0.0-beta1 (and powershell version 2.0.0), then later try to install foo 2.0.0, the second module install will silently fail.

Expected Behavior

Installing the released version of a module should supercede the prerelease version.

(this would likely also impact other pre-release versions - i.e. upgrading from beta1 to beta2)

Current Behavior

Attempting to install the released version over a pre-release fails silently.

Steps to Reproduce (for bugs)

register-PSModuleRepository -name PreReleaseTest -SourceLocation https://www.myget.org/F/usepowershell/api/v2 
install-module PSConfAsia -allowprerelease -maximumversion 2.0.0-alpha-Repository PreReleaseTest -scope CurrentUser

## Print the version from PSGetModuleInfo
## Note the 2.0.0-alpha
([xml](cat ~\Documents\WindowsPowerShell\Modules\PSConfAsia\2.0.0\PSGetModuleInfo.xml -raw)).SelectNodes("//*[@N='NormalizedVersion']").'#text'

install-module PSConfAsia --maximumversion 2.0.0 -repository PreReleaseTest -scope CurrentUser

## Print the version from PSGetModuleInfo
## Still alpha
([xml](cat ~\Documents\WindowsPowerShell\Modules\PSConfAsia\2.0.0\PSGetModuleInfo.xml -raw)).SelectNodes("//*[@N='NormalizedVersion']").'#text'

install-module PSConfAsia --maximumversion 2.0.0 -repository PreReleaseTest -scope CurrentUser -force

## Print the version from PSGetModuleInfo
## How we have the release version
([xml](cat ~\Documents\WindowsPowerShell\Modules\PSConfAsia\2.0.0\PSGetModuleInfo.xml -raw)).SelectNodes("//*[@N='NormalizedVersion']").'#text'

> $PSVersionTable

 LoECDA-PS > $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.16299.98
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.16299.98
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

> Get-Module -ListAvailable PowerShellGet,PackageManagement

    Directory: C:\Users\stmuraws\Documents\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.1.7.0    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource...}
Script     1.6.0      PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}


    Directory: C:\Program Files\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Binary     1.0.0.1    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource...}
Script     1.0.0.1    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}

[ghost]

This should fail, but not silently, based on normal PSGet handling of installing a newer version with Install-Module (I think). If I am missing something, please help me figure it out...
At home, I happen to have an old version of posh-git installed (some spaces removed)
PS C:\WINDOWS\system32> find-module posh-git
Version Name Repository Description

---

0.7.1 posh-git PSGallery Provides prompt with Git status summary informat...

PS C:\WINDOWS\system32> get-installedmodule posh-git
Version Name Repository Description

---

0.5.0.2015 posh-git PSGallery A set of PowerShell scripts which provide Git/Po...

PS C:\WINDOWS\system32> install-module posh-git
WARNING: Version '0.5.0.2015' of module 'posh-git' is already installed at 'C:\Program
Files\WindowsPowerShell\Modules\posh-git\0.5.0.2015'. To install version '0.7.1', run Install-Module and add the -Force
parameter, this command will install version '0.7.1' in side-by-side with version '0.5.0.2015'.

[smurawski]

@JKeithB Your example has different version numbers.. mine is when the version number is the same, but one is a pre-release version. You get no prompt about the module being present already when you try install the module again. Side by side won't work in this case, because as far as PowerShell is concerned, the modules have the same version. The pre-release information is only part of the nuget package.

[ghost]

@smurawski do understand the difference. Good feedback, and thanks.
The reason we have the error is that prerelease version 2.0.0-beta is treated a lesser version than the stable version 2.0.0, but because the versions are same we skip the errors. Either way, we aren't generating any information to the user to tell them that (a) the action failed and (b) what to do.

[ghost]

@smurawski Had to modify this after the initial posting to cover all cases, including the specific instance you listed.
We talked through this, and want to clarify why we are choosing the behavior: it's about consistency. We will have to generate the proper errors, using the following mini-spec.

Ignoring prerelease versions for a moment, when a version X of a module exists on the system, and a version X+ is the higher-level version that's available, then:
install-module -requiredversion X #is a silent no-op, verbose shows nothing is done;
install-module #does not update to X+, warning says you must use -force
install-module -minimumversion X+ #does not update to X+, warning says you must use -force
install-module -maximumversion X+ #does not update to X+, warning says you must use -force
install-module -requiredversion X+ #succeeds, user was specific about requiredversion X+ install-module -requiredversion X+ -force #succeeds
Note that if the user is specific about a single version, we treat that as equivalent to -Force and proceed. This change was made due to user feedback. However, if there is any guesswork required (such as specifying minimumversion, maximumversion, or not specifying any version) then the command will not do anything and will give the user a warning message to use -Force.

With prerelease versioning, in the docs we describe Prerelease versioning impact on sort order and installation folders. In that we explain that:
prerelease version X-string2 is greater than X-string1 if string2 alphabetically sorts greater than string1
EXCEPT FOR
stable release version X is defined to be greater than any prerelease version X-ANYString

Following these rules: if prerelease version X-S1 is installed, and prerelease X-S2 is the current max version available:
install-module -requiredversion X-S1 #is a silent no-op, verbose shows nothing is done;
install-module #NO update to X-S2, warning says you must use -force
install-module -minimumversion X-S2 #NO update to X-S2, warning says you must use -force
install-module -maximumversion X-S2 #NO update to X-S2, warning says you must use -force
install-module -requiredversion X-S2 #succeeds, specified requiredversion X-S2
install-module -force #succeeds

And the same behavior if prerelease X-S1 is installed, and stable version X with no prerelease string is the current max version available:
install-module -requiredversion X-S1 #is a silent no-op, verbose shows nothing is done;
install-module #NO update to X, warning says you must use -force
install-module -minimumversion X #NO update to X, warning says you must use -force
install-module -maximumversion X #NO update to X, warning says you must use -force
install-module -requiredversion X #succeeds, user was specific about requiredversion X install-module -force #succeeds

[Jaykul]

Ohhhh nooooo ....

This won't work AT ALL if your module has a binary and is loaded in any PowerShell session.

Also, it affects installs of other pre-release versions as well as the eventual final release.

Real world example: PSReadLine 2.0.0-beta2 just got released, and can't be installed by anyone using the previous beta.

[SteveL-MSFT]

@edyoung we need to get this fixed before PSReadLine 2.0.0 release

[edyoung]

That's an interesting one. Because the install path only has the base version in its name, eg C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0, upgrading beta1 to beta2 wants to overwrite the files - which it can't if the files are open.

Not too sure what the options are to fix, will have to think about it. We can't unload DLLs from the running process, and I don't think we have a ton of freedom to rename these files.

Particularly awkward for PSReadLine, since it gets autoloaded. A lousy workaround: close all powershell windows and from cmd.exe run
powershell -command "install-module psreadline -requiredversion 2.0.0-beta2 -AllowPrerelease -Force -AllowClobber"

[edyoung]

@SteveL-MSFT I believe PowerShell/PowerShell#2983 would be best way to resolve - then psreadline-2.0.0-beta1 would be installed in a separate directory from psreadline-2.0.0-beta2 because the dir would include the full SemVer.

If we can't fix in the interim I think it would make sense to release the next production build of PSReadLine as 2.0.1 instead of 2.0.0 - goofy, I know.

[anamnavi]

This works now and will be resolved by PR #523 to be released in 3.0.12 preview release soon. You still can't install two versions side by side which have the same powershell version part (i.e 2.2.0-beta1 and 2.2.0-beta2 and 2.2.0 all have the same powershell version part. But installing a stable version over prerelease one won't require force: