Monikers, Release Channels, and more

[Kaleb Luedtke (Trenly)]

I am wondering how exactly monikers work as we move towards the 1.1 schema. My primary question is - What happens if there are different monikers for versions of the same package. I'll use the example of Ubuntu.

With ubuntu, there are a few release channels, primarily 1604, 1804, and 2004. Each of these channels have their own update cadence. The approach for 1.0 has been to split these into different packages so they can be managed independently. However, this sparked the question in my mind as to how monikers actually work. If the packages were in the below structure, what would happen?

../manifests/c/Canonical/Ubuntu
  /1604.xx.xx.01 (Moniker: ubuntu-16.04)
  /1604.xx.xx.02 (Moniker: ubuntu-16.04)
  /1804.xx.xx.xx (Moniker: ubuntu-18.04)
  /2004.xx.xx.xx (Moniker: ubuntu-20.04)

I would imagine that a search for ubuntu would return v2004 since that is the latest version. But, what would happen if a user tried winget search ubuntu-16.04 ? Would it show v2004, since that is the latest version in Canonical.Ubuntu? Would it show 1604.xx.xx.02, since that is the latest with a matching moniker? Would it return no results? How does this actually work?

This brings to question how release channels will work for a single package. Using the example from above, would the different release channels have their monikers handled separately? Will the channels show as separate entries in winget search, or will they only be visible through winget show? I looked at the specs folder and don't see any documentation on it, so I was hoping that we could (1) get some information on how the channels will be implemented, if that discussion has already been had, or (2) start documenting/speccing how the 1.1 schema keys will be implemented for the community to provide their feedack

[Demitrius Nelon (denelon)]

A moniker is a special type of tag. If only one package uses a moniker, it will be installed via winget install <moniker> as in the example for vscode winget install vscode. Things become a bit more tricky if more than one package uses the same moniker across all configured sources. In the event that happens, the user will be asked to disambiguate.

We've had topical discussions about channels across multiple "Issues", "Discussions", and "PRs". The main scenario we've come to align on is channels should be used when it's not possible to have "side by side" installations. Docker Desktop comes to mind here. Other programs like Ultimaker Cura, and Visual Studio Code support "side by side" install.

Channels aren't named consistently across different packages. We will likely need to support arbitrary names for channels, and have some sort of key to identify the "stable"/"primary" channel for the default install scenario. Some packages also don't identify what channel they are via Apps & Features, so we will need a way to track what was installed to be able to provide a hint to the CLI when the default channel isn't used.

I believe our current thinking is to have a single manifest with support for channels when the version is the same, or when builds get promoted to a different channel, and the version doesn't get modified. We would welcome ideas or suggestions for what makes sense here. If there are experts with other package managers, we would also like to avoid breaking muscle memory. It would be good to see how people prefer to use this capability.