PSResourceGet
PSResourceGet copied to clipboard
Auto-Update and New Version Notification for PowerShellGallery Modules imported/installed
Summary of the new feature / enhancement
Related to #495
Problem Statement
Module owners have difficulty getting users to upgrade to the latest stable version of their module. This means that users are often are on older and worse versions of modules, which has the potential to have security flaws, breaking bugs and issues.
Potential Solution
Have PowerShellGet somehow check for newer versions with the PowerShellGallery automatically and in the background. There are two approaches to encourage updating to the latest version
-
Notify the user with a prompt explaining there current module is not the latest release and they should update via
Update-PSResource -Name <MODULE_NAME>- Potential notification
There is a version of <MODULE_NAME> available from the PowerShellGallery, would you like to install it? [Y] Yes [N] No:
- Potential notification
-
Allow the users to opt into automatic updates for specified modules
- When installing specific module (parameter
-EnableAutoUpdatefor example) - Or later configuration
- When installing specific module (parameter
Proposed technical implementation details (optional)
Potential Example Scenarios
On terminal startup (module import)
When the user opens a new PowerShell terminal, a check of the imported modules for newer versions is ran to notify the users that ModuleA, ModuleB...etc has a newer version available on PowerShellGallery.
On cmdlet use
User uses a cmdlet from a specific PowerShell module, <ModuleA_Cmdlet>, after cmdlet is run, a check against that module is run and user is notified if there is a newer version available.
When installing module
When installing a module user has a -EnableAutoUpdate Parameter they can set with Install-PSResource to have PowerShellGet auto-update module on import.
Security Considerations
In the scenarios for auto-updating, there would have to be some form of package signing within PowerShell Gallery. If a previous version of a package was signed, then the next version should be signed with the same certificate. Additionally have a way to override this requirement to account
Opening this up for discussion, please feel free to add any additional scenarios, thoughts, and considerations. I included some of the main scenarios I believe might be good.
cc: @SteveL-MSFT @alerickson @anamnavi @SydneyhSmith
I like both options presented.
Another scenario that should be considered at some point, are private repositories with and without authentication.
Either with PowerShell Gallery or private repositories I would expect that if updates are enabled that updates are checked when the module is loaded. If the module is being loaded interactively it could prompt to complete the update for the user and then load the new module. However, if the module is not being loaded interactively a warning could be written notifying them that the update is available and they should manually update it by running Update-PSResource -Name <MODULE_NAME> -Repository <RepositoryName>.
- Should check when the module is imported but not be a blocking action.
- Should only check the PSRepository the module was installed from unless otherwise configured.
- If the module is prerelease, it should look for new prereleases.
This auto update feature is missing consideration for modules that follow semantic versioning in regards to major versions and breaking changes. I would not want auto update or a notification/warning to a version of the module that is incompatible with my current system.
For example, Pester 4.x to 5.x is a major version change with breaking changes and can require changes to my scripts to be compatible.
In the original RFC there was a parameter for Update-PSResource called UpdateTo that allowed the user to specify if they only wanted to take minor versions or include major versions. This auto update feature would need that same configuration on a per module basis.
A
-UpdateToparameter has valuesMinorVersion(as default),MajorVersion,PatchVersion.MajorVersionallows updating to latest major version.PatchVersionallows updating to latest patch version (e.g. 6.2.1 to 6.2.4).
https://github.com/PowerShell/PowerShell-RFC/pull/185/files#diff-3543dd227ba0e5d6aa1adb426c03d460807134ca378489b072e91e5c4dda2845R335-R337
This could be avoided if module authors could specify module dependencies in the module manifest the same way NuGet does with version ranges. Take PSKoans as an example that has a dependency on Pester. The module author has to pin his module to a specific version of Pester in order for his module not to load/install Pester 5.x. However, this also would prevent his module from taking any patches on the Pester 4.x line if a new version was released without a new PSKoans version with the updated Pester dependency.
Related issue about update notifications: https://github.com/PowerShell/PowerShellGet/issues/91