Specification: Release Channels#6294
Conversation
Specification for channel-aware package management — subscribe to stable/beta/dev/canary/LTS channels per package with upgrades scoped within the subscribed channel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
|
||
| ## Solution Design | ||
|
|
||
| ### Manifest Schema Extension (v1.29.0) |
|
|
||
| ### Manifest Schema Extension (v1.29.0) | ||
|
|
||
| Add a `Channel` field to the version manifest: |
There was a problem hiding this comment.
This already exists in the installer manifest at the installer or root level, allowing for the possibility of multiple channels in a single manifest
| - Both `Google.Chrome` with `Channel: Beta` AND `Google.Chrome.Beta` exist simultaneously | ||
|
|
||
| **Phase 2 — Transition (v1.30.0):** | ||
| - `Google.Chrome.Beta` marked as deprecated alias pointing to `Google.Chrome` channel `Beta` |
There was a problem hiding this comment.
There is no alias function currently. This would rely on package tombstones
|
|
||
| Packages currently using separate IDs for channels (e.g., `Google.Chrome.Beta`): | ||
|
|
||
| **Phase 1 — Introduction (v1.29.0):** |
| **Phase 2 — Transition (v1.30.0):** | ||
| - `Google.Chrome.Beta` marked as deprecated alias pointing to `Google.Chrome` channel `Beta` | ||
| - Installing `Google.Chrome.Beta` shows: "This package ID is deprecated. Use 'winget install Google.Chrome --channel beta' instead." | ||
| - Upgrades of `Google.Chrome.Beta` transparently resolve to `Google.Chrome` channel `Beta` |
There was a problem hiding this comment.
Need more detail on how this would be achieved - no mechanism exists today
| - Installing `Google.Chrome.Beta` shows: "This package ID is deprecated. Use 'winget install Google.Chrome --channel beta' instead." | ||
| - Upgrades of `Google.Chrome.Beta` transparently resolve to `Google.Chrome` channel `Beta` | ||
|
|
||
| **Phase 3 — Deprecation (v1.31.0+):** |
| Install-WinGetPackage -Id "Google.Chrome" -Channel "Dev" | ||
|
|
||
| # List with channel info | ||
| Get-WinGetPackage -IncludeChannel |
There was a problem hiding this comment.
Why a separate switch? Users can use Select-Object -Property for showing specific properties
|
|
||
| Add a `Channel` field to the version manifest: | ||
|
|
||
| ```yaml |
There was a problem hiding this comment.
This seems to assume that a package version can only exist in a single channel at the same time - which conflicts with real flighting rules where the same version could be in Dev, Canary, and Insiders all at the same time.
Need more detail on how versions move between channels and multi-channel support. Keeping the field at the installer level may make sense, as new installer nodes can be added to the manifest as the flighting progresses
There was a problem hiding this comment.
Maybe we could make a Channels field that can take a list of them.
There was a problem hiding this comment.
I like this idea; Especially since then we could just add a new version with the appropriate channels and then as it gets promoted, update the channels without having to do the full installer re-scan
|
|
||
| ### Schema Version | ||
|
|
||
| Requires manifest schema version 1.29.0 for the `Channel` field. |
There was a problem hiding this comment.
Remove version-specific information
| ```yaml | ||
| PackageIdentifier: Google.Chrome | ||
| PackageVersion: 127.0.6533.0 | ||
| Channel: Dev |
There was a problem hiding this comment.
Could a version have multiple channels? This happens a lot with runtimes - a developer might install OpenJS.NodeJS 24.x (current LTS), for an app they're working on. If they subscribed to LTS instead of 24.x, they would receive 26.x when it becomes LTS in October, potentially breaking their app.
Speaking of dependencies, would packages be able to depend on a specific channel of a different package?
- Remove version-specific numbers from headings and references - Acknowledge existing installer-level Channel field - Document multi-channel version support and ARP detection challenges - Defer migration/alias mechanism to future spec (tombstones TBD) - Remove -IncludeChannel PowerShell switch (use Select-Object) - Add LTS semantics and cross-package deps to Future Considerations Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| @@ -0,0 +1,388 @@ | |||
| --- | |||
| author: Demitrius Nelon denelon, GitHub Copilot Copilot | |||
There was a problem hiding this comment.
They're even adding Copilot to Copilot. What has the world come to?
| Add a `Channel` field to the version manifest: | ||
|
|
||
| > [!NOTE] | ||
| > The `Channel` field already exists in the installer manifest at the installer and root level. This spec extends the channel concept to the version level for subscription tracking and version resolution, while acknowledging that a single package version can exist in multiple channels simultaneously. |
There was a problem hiding this comment.
What is the version level? The root level of a manifest is already a single specific package version.
|
|
||
| Add a `Channel` field to the version manifest: | ||
|
|
||
| ```yaml |
There was a problem hiding this comment.
Maybe we could make a Channels field that can take a list of them.
|
|
||
| When a package is installed or updated outside of WinGet, there is no reliable mechanism for WinGet to determine which channel the installed version belongs to. This varies by installer type: | ||
|
|
||
| - **MSIX/AppX** — Channel can often be identified from the package identity itself |
There was a problem hiding this comment.
Not really. For example, winget itself
| When a package is installed or updated outside of WinGet, there is no reliable mechanism for WinGet to determine which channel the installed version belongs to. This varies by installer type: | ||
|
|
||
| - **MSIX/AppX** — Channel can often be identified from the package identity itself | ||
| - **MSI/EXE** — Registry entries (ARP) rarely encode channel information; the same version number may exist in multiple channels with no distinguishing metadata |
There was a problem hiding this comment.
Do we have a list of examples of what apps do?
I imagine some will use different product codes for different channels.
If someone adds the channel to the display name, maybe we could have a chance at parsing it from there during normalization.
There was a problem hiding this comment.
I've seen:
DisplayVersion-CozyCloud.CozyDrive.Betauses4.1.0-beta.3DisplayName-AdGuard.AdGuard.BetausesAdGuard BetaProductCode-Brave.Brave.BetausesBraveSoftware Brave-Browser-Beta
|
|
||
| | Setting | CLI Argument | Description | | ||
| |---------|-------------|-------------| | ||
| | `defaultChannel` | `--channel` | Default channel for new installations (empty = stable) | |
There was a problem hiding this comment.
I don't think we'd want this a global, especially with all apps potentially choosing different naming schemes.
| | `showChannelInList` | `--include-channel` | Always show channel column in `winget list` | | ||
| | `showChannelInUpgrade` | `--include-channel` | Always show channel column in `winget upgrade` | |
There was a problem hiding this comment.
Why would we want to hide the cable column?
4 participants
📖 Description
Specification for release channel support in WinGet. Users subscribe to a channel (stable/beta/dev/canary/LTS) per package and receive upgrades only within that channel. Includes manifest schema extension, channel-aware version resolver, and Group Policy controls.
Changes addressing review feedback (June 22):
-IncludeChannelPowerShell switch (useSelect-Object)Authored with GitHub Copilot assistance.
🔗 References
Related Issues:
🔍 Validation
Spec document — no code changes to validate.
✅ Checklist
📋 Issue Type
Microsoft Reviewers: Open in CodeFlow