microsoft / microsoft/winget-cli

version specific feature

Open
#227 2 comments 34 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue-Feature
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

Relevant area(s)
  • WinGet CLI
Description of the new feature / enhancement

winget install --version <version> currently requires an exact version match. This request is to support semantic-version-style selection, so a user can install the latest version within a range without knowing the exact build.

Examples:

  • winget install node --version 12 → install the latest 12.x.y (latest minor + patch within major 12)
  • winget install node --version 12.16 → install the latest 12.16.x (latest patch within 12.16)

Full exact versions already work today (e.g. --version 12.16.3).

Proposed technical implementation details
  • Interpret a partial version as a range and resolve to the highest available version matching the specified prefix.
  • Define behavior when no version matches the prefix, and how this interacts with pinning and upgrade.
  • WinGet already supports wildcard/gated versions for pinning; a similar matching approach could apply to install/upgrade version selection.
Alternative syntax under consideration

In addition to the --version flag, an inline separator syntax has been proposed (originally by @lietu in #406) so a version can travel with the package identifier in a list — familiar from Chocolatey/Scoop workflows:

  • winget install "Node.js@12.16.3" (or a variant such as ==)

This is a syntax variation of the same underlying capability and is being considered alongside the semantic-version-part selection above. Consolidating it here so the idea isn't lost.

Out of scope
  • Commit-hash selection (e.g. --version <sha>) — WinGet doesn't have this kind of source data.
  • Branch / tag / channel selection (e.g. --version experimental) — tracked separately as release channels in #147.
Notes
  • Possibly related: #120, #163, #216, #406.

Updated with GitHub Copilot.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by tracing WinGet CLI handling of --version and the existing wildcard or gated version matching used for pinning. Define the highest-prefix match, no-match behavior, and interactions with pinning and upgrade, then validate the install examples and any separator syntax.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.