Open StevenBucher98 opened 3 years ago
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>
.
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
-UpdateTo
parameter has valuesMinorVersion
(as default),MajorVersion
,PatchVersion
.MajorVersion
allows updating to latest major version.PatchVersion
allows updating to latest patch version (e.g. 6.2.1 to 6.2.4).
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
Should have settings for auto-update, minor version, major version, security only, etc... and presenting as a FeedbackProvider notification maybe a background thread run once a day to perform a check and show what is updatable and what should be updated.
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>
There is a version of <MODULE_NAME> available from the PowerShellGallery, would you like to install it? [Y] Yes [N] No:
Allow the users to opt into automatic updates for specified modules
-EnableAutoUpdate
for example)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 withInstall-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