Summary of the new feature / enhancement
This is an issue to help build the potential learning path for developing new PowerShell Features, that as part of development and publishing to Preview and then STS/LTS could make use of Experimental Features. This is a reasonably good candidate, due to the different area's that this hits, and with there being potential for futeur aspects of configuration of these enhancements in logic to be contained in 1 or more of system/user powershell profile, EnvVars, RegKeys powershell.config.json or GPO settings, or even from a profile script or other system entirely. There is also the potential implementation of a priority ordering mechanism to favour one of the prior mentioned above the rest. This is why it makes for a good learning excercise, along with lessons learned at the end of this.
The content from this could end up as a Learn.Microsoft learning path.
It also brings up a number of interesting areas to discuss around inclusive design practices & providing easy scalable configrable options.
Note - That doesn't mean an outcome from this will make it beyond a learning & teaching excercise (at least not for me @kilasuit) - with work on this already started and continuing in a branch in my fork.
That said, we have some areas where improvements to this could be undertaken & across previous issues & discussions there have been things that have been asked for by different parts of the community, the below just some that I can remember off the top of my head.
WinGet related
General
Stretch goals
Most of the above, may never make it into the end product, but as a learning exercise will allow for deeper understanding of all the differnt moving parts needed for what seems simple enough on the surface for providing a notification there is a new update.
Note - most of the above has already been mostly planned & investigated, and is something that I had intended recording for Global Azure and PowerShell.org.uk Gathering on May 10th this year but that failed due to tech issues because I am using old tech that I need to replace but I intend to sometime in the future record content like this, just is in my every growing todo list
Other details inc previous issue content.
As an admin, across Windows based devices, I likely have specified how PowerShell should be updated by opting into the update being pushed to devices from MicrosoftUpdate, either at or post install, using documented RegKeys/EnvVars & as such I nor my users should be informed of any updates in the session via it's current mechanism & would prefer this check be better controlled as a background task instead of being a blocker to getting a session up and running.
We should, have a lookup based on how the installation was performed and how it should be managed that is set either as a EnvVar/RegKey/powershell.config.json setting.
As an admin, across a cross platform and complex environment for software deployment, may have Windows, Mac & Linux devices and have a mechanism already in ensuring that all devices are properly updated in line with existing policies, that may include stage-gated updates across variety of devices and users, including across multiple devices to a single or multiple different regular users.
This is particularly true if I've chosen to stay on an LTS release and do not want to get a notification of when STS releases are made in either mine or my users sessions, as this slows me/them down & can add unnecessary additional frustration by showing this message where this could be controlled or displayed to the user in a different manner that provides less friction.
This is an area I did look into about how I think it could be implemented and whilst I think I understand the pieces that need to be inplace to meet this user story from running back through things in this comment and it's links, I did not start work on changing this yet to allow me/others time to think more on this or to potentially implement the needed changes.
I also personally intend on having this as a process better automated, that is more flexible than this current process and will end up built into how my prompt is built as part of releasing a repo with how I currently manage my ever changing and complex profile based on learnings from trying to understand how this works today.
Proposed technical implementation details (optional)
I think there'd need to be a small additional logic check added in the src/Microsoft.PowerShell.ConsoleHost/host/msh/UpdatesNotification.cs file to accomoplish this that would bypass running the rest of the check.
It perhaps requires either additional env var or an addition to powershell.config.json file to allow better control of this, particularly if you/admins may want a blanket "don't show` if current user is in a specific group of users, irrespective of them running in an admin session or not that continues to work across platforms in a consistent manner and ideally ties into other existing install/update processes.
We may also want the update check to instead of being a daily check be more configurable to being checked at a specific time of the day, particularly if we ever re-add daily builds or add other builds that we may want to follow, like in how I was using BuildDownloader to deal with downloading and testing artifacts from PR builds, which I still need to record and show how to use this effectively in future.
Summary of the new feature / enhancement
This is an issue to help build the potential learning path for developing new PowerShell Features, that as part of development and publishing to Preview and then STS/LTS could make use of Experimental Features. This is a reasonably good candidate, due to the different area's that this hits, and with there being potential for futeur aspects of configuration of these enhancements in logic to be contained in 1 or more of system/user powershell profile, EnvVars, RegKeys
powershell.config.jsonor GPO settings, or even from a profile script or other system entirely. There is also the potential implementation of a priority ordering mechanism to favour one of the prior mentioned above the rest. This is why it makes for a good learning excercise, along with lessons learned at the end of this.The content from this could end up as a Learn.Microsoft learning path.
It also brings up a number of interesting areas to discuss around inclusive design practices & providing easy scalable configrable options.
Note - That doesn't mean an outcome from this will make it beyond a learning & teaching excercise (at least not for me @kilasuit) - with work on this already started and continuing in a branch in my fork.
That said, we have some areas where improvements to this could be undertaken & across previous issues & discussions there have been things that have been asked for by different parts of the community, the below just some that I can remember off the top of my head.
WinGet related
General
Stretch goals
Most of the above, may never make it into the end product, but as a learning exercise will allow for deeper understanding of all the differnt moving parts needed for what seems simple enough on the surface for providing a notification there is a new update.
Note - most of the above has already been mostly planned & investigated, and is something that I had intended recording for Global Azure and PowerShell.org.uk Gathering on May 10th this year but that failed due to tech issues because I am using old tech that I need to replace but I intend to sometime in the future record content like this, just is in my every growing todo list
Other details inc previous issue content.
As an admin, across Windows based devices, I likely have specified how PowerShell should be updated by opting into the update being pushed to devices from MicrosoftUpdate, either at or post install, using documented RegKeys/EnvVars & as such I nor my users should be informed of any updates in the session via it's current mechanism & would prefer this check be better controlled as a background task instead of being a blocker to getting a session up and running.We should, have a lookup based on how the installation was performed and how it should be managed that is set either as a EnvVar/RegKey/powershell.config.json setting.
As an admin, across a cross platform and complex environment for software deployment, may have Windows, Mac & Linux devices and have a mechanism already in ensuring that all devices are properly updated in line with existing policies, that may include stage-gated updates across variety of devices and users, including across multiple devices to a single or multiple different regular users.
This is particularly true if I've chosen to stay on an LTS release and do not want to get a notification of when STS releases are made in either mine or my users sessions, as this slows me/them down & can add unnecessary additional frustration by showing this message where this could be controlled or displayed to the user in a different manner that provides less friction.
This is an area I did look into about how I think it could be implemented and whilst I think I understand the pieces that need to be inplace to meet this user story from running back through things in this comment and it's links, I did not start work on changing this yet to allow me/others time to think more on this or to potentially implement the needed changes.
I also personally intend on having this as a process better automated, that is more flexible than this current process and will end up built into how my prompt is built as part of releasing a repo with how I currently manage my ever changing and complex profile based on learnings from trying to understand how this works today.
Proposed technical implementation details (optional)
I think there'd need to be a small additional logic check added in the src/Microsoft.PowerShell.ConsoleHost/host/msh/UpdatesNotification.cs file to accomoplish this that would bypass running the rest of the check.
It perhaps requires either additional env var or an addition to powershell.config.json file to allow better control of this, particularly if you/admins may want a blanket "don't show` if current user is in a specific group of users, irrespective of them running in an admin session or not that continues to work across platforms in a consistent manner and ideally ties into other existing install/update processes.
We may also want the update check to instead of being a daily check be more configurable to being checked at a specific time of the day, particularly if we ever re-add daily builds or add other builds that we may want to follow, like in how I was using BuildDownloader to deal with downloading and testing artifacts from PR builds, which I still need to record and show how to use this effectively in future.