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
|
|
||
| ### Schema Version | ||
|
|
||
| Requires manifest schema version 1.29.0 for the `Channel` field. |
There was a problem hiding this comment.
Remove version-specific information
2 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, migration path for packages currently using separate IDs per channel, and Group Policy controls.
Authored with GitHub Copilot assistance.
🔗 References
Related Issues:
🔍 Validation
Spec document — no code changes to validate.
✅ Checklist
📋 Issue Type
Microsoft Reviewers: Open in CodeFlow