[release/v7.4.15] Delay update notification for one week to ensure all packages become available#27229
Conversation
There was a problem hiding this comment.
Pull request overview
Backport to release/v7.4.15 that delays showing update notifications on startup until an update has been available for one week, reducing the chance users are prompted before packages are fully available across distribution channels.
Changes:
- Added a 7-day notification delay gate before printing update messages.
- Introduced constants for notification delay and update-check backoff (replacing a hardcoded
7in one location). - Updated update-file parsing call site to consume the persisted publish date for delay logic.
Comments suppressed due to low confidence (1)
src/Microsoft.PowerShell.ConsoleHost/host/msh/UpdatesNotification.cs:188
- The comment here hard-codes “1 week”, but the logic now uses
UpdateCheckBackoffDays. To avoid the comment drifting if the constant changes, consider rewording it to reference the backoff interval (or the constant name) rather than a fixed duration.
if (parseSuccess && updateFilePath != null && (today - lastUpdateDate).TotalDays < UpdateCheckBackoffDays)
{
// There is an existing update file, and the last update was less than 1 week ago.
// It's unlikely a new version is released within 1 week, so we can skip this check.
return;
| DateTime today = DateTime.UtcNow; | ||
| if ((today - lastUpdateDate).TotalDays < NotificationDelayDays) |
There was a problem hiding this comment.
lastUpdateDate comes from TryParseUpdateFile() which parses a date-only string using DateTimeStyles.AssumeLocal, but this comparison uses DateTime.UtcNow. That mixes local and UTC day boundaries and can shift the effective delay by up to ~1 day depending on the user's timezone. Consider comparing using a consistent basis (e.g., compare DateTime.Today to lastUpdateDate.Date, or parse/normalize lastUpdateDate as UTC and compare to UtcNow.Date).
| DateTime today = DateTime.UtcNow; | |
| if ((today - lastUpdateDate).TotalDays < NotificationDelayDays) | |
| DateTime today = DateTime.Today; | |
| if ((today - lastUpdateDate.Date).TotalDays < NotificationDelayDays) |
| DateTime today = DateTime.UtcNow; | ||
| if ((today - lastUpdateDate).TotalDays < NotificationDelayDays) | ||
| { | ||
| // The update was out less than 1 week ago and it's possible the packages are still rolling out. | ||
| // We only show the notification when the update is at least 1 week old, to reduce the chance that | ||
| // users see the notification but cannot get the new update when they try to install it. | ||
| return; | ||
| } | ||
|
|
||
| string releaseTag = lastUpdateVersion.ToString(); |
There was a problem hiding this comment.
On the first startup where (today - lastUpdateDate) crosses NotificationDelayDays, ShowUpdateNotification() can show a notification based on a stale update file before CheckForUpdates() has run (it starts in the background and has an initial 3s delay). This can result in prompting for an older release even when a newer one is available. One option is to only show notifications after a successful update check has completed for the current day (e.g., gate on today’s .done file), or otherwise ensure the cache is refreshed before showing once the delay has elapsed.
Backport of #27095 to release/v7.4.15
Triggered by @daxian-dbw on behalf of @daxian-dbw
Original CL Label: CL-General
/cc @PowerShell/powershell-maintainers
Impact
REQUIRED: Choose either Tooling Impact or Customer Impact (or both). At least one checkbox must be selected.
Tooling Impact
Customer Impact
Delays startup update notifications until a release has been available for one week so users are less likely to see an upgrade prompt before packages are fully published across distribution channels.
Regression
REQUIRED: Check exactly one box.
This is not a regression.
Testing
The backport cherry-pick applied cleanly to release/v7.4.15. The change is isolated to UpdatesNotification logic, preserving the existing update-check flow while delaying notification display and maintaining the one-week backoff interval. CI on the backport PR will validate the updated build and test matrix.
Risk
REQUIRED: Check exactly one box.
Medium risk because the change affects user-visible update notification behavior on startup, but it is scoped to a single notification component and does not alter core command execution.