Support different release channels [released, beta, alpha]

[denelon]

I'd like to be able to use the package manager for different channels of software. This could be beta, or unstable branches, or other kinds of constructs.

Semantic versioning (https://semver.org) has a specification we may follow for pre-release software.
Microsoft has channels.
Many open source projects have branches.

Note: Some packages support "side by side" install where a stable and a pre-release version may both be on a system at the same time. These are not considered release channels in the Windows Package Manager, but they are treated as different packages. Release channels are considered in the context of the Windows Package Manager for packages that do not support "side by side" installation.

[denelon]

If this is a feature you'd like to see supported and you have an example of how the software is published, please share this to help us gather data on the best way to proceed.

[utybo]

Java (AdoptOpenJdk) is a good example for this. There are two LTS releases at the moment (versions 8 and 11) and the current release is 14. This feature would be useful for having at least the option to install version 8 or 11.

It might also be possible to just have different packages (e.g. openjdk8 and openjdk11, that's what Ubuntu is using I believe) but that feels less clean.

Also, all Java versions can be installed side-by-side, so winget should probably support having e.g. versions 8 and 11 installed at the same time. (they're in separate directories when installed manually)

[ocdtrekkie]

The ideal scenario (which is familiar to Linux folks, I believe), is that openjdk or openjdk-latest should install the newest supported release, and openjdk-8 or openjdk-11 or the like should be maintained packages respectively, so that people can script opening the release version they need.

The best solution, I think, is to require major version numbers for packages with multiple supported releases, and then winget needs to support "shortcuts", such that running winget install openjdk is understood to install openjdk-14. And when a newer OpenJDK package comes out, that shortcut can be pointed to the newer release, without breaking users who are explicitly trying to install openjdk-14.

[cnshenj]

Chocolatey: --version
NuGet: -Version
Docker: name:tag
npm: name@tag

Personally I like the npm format.

[rashil2000]

Another example of this would be the Node.js package. Many times the recommended version is nodejs-lts, but when installing Node through winget, it installs the current (latest) release, which is not very widely supported. The same is the case with .Net Core. The default installation version should be the Long Term Support version, or we should have some way of specifying it, instead of manually feeding the version numbers every time.

[KorbenDev]

I want to support this. Today my script tried to download and install a 7Zip alpha(!) version. First I want to question the need to distribute alpha/beta versions over package management in general. I don't think that's a good idea.
And if you really want to make alpha/beta state applications available, they should be tagged very clearly!
That leads back to my request of using semantic versioning. The version of the 7Zip package is 20.0.0-alpha. WTF??? Do I really have to check for "alpha", "beta", "test" and all the other naming someone could think of, probably also in different languages, to avoid not released software?
Sorry, but for me personal this issue is just getting annoying.

[ocdtrekkie]

@KorbenDev mildly horrifying.

@KevinLaMS it looks like you did the manual approval steps on microsoft/winget-pkgs#2088 ...what happened here? Has the Package Manager team defined any sort of policy or procedure regarding release channels and the stability of versions that should be accepted into winget?

[tusharb86]

Pinging @KevinLaMS and @denelon for an update here. I went to install 7zip and found that it would be an alpha version (20.0.0-alpha). This is not something I want to install on my development machine and expected that I would be installing the latest stable release of 7zip (19.00)... Can we please revert microsoft/winget-pkgs#2088?

[ocdtrekkie]

This is probably why @kayone shouldn't have given up just because Microsoft entered the space. Months later, Microsoft appears to be unable to decide how to handle this, when handling decisionmaking on what releases to push is fundamental to operating a good package manager.

[peterlewis]

Pinging @KevinLaMS and @denelon for an update here. I went to install 7zip and found that it would be an alpha version (20.0.0-alpha). This is not something I want to install on my development machine and expected that I would be installing the latest stable release of 7zip (19.00)... Can we please revert microsoft/winget-pkgs#2088?

I agree. Can we at least, for now, consider adopting the same behaviour as is done for Visual Studio Code to differentiate it from Visual Studio Code Insiders?

I've drafted a PR that follows the example of VSCode/VSCode Insiders and that I believe would sort the 7-Zip issue that @tusharb86 raised. Would welcome thoughts from all (@KevinLaMS and @denelon too, perhaps?).

[peterlewis]

@KorbenDev and @tusharb86 - Hopefully, at least in the case of 7-Zip, this will now be resolved. See:

microsoft/winget-pkgs#3756 - Create 7-Zip 20.02 Alpha in separate listing
microsoft/winget-pkgs#3762 - Remove 1 of 2 'alpha'-designated version of 7-Zip from non-alpha listing
microsoft/winget-pkgs#3807 - Remove 2 of 2 'alpha'-designated version of 7-Zip from non-alpha listing

[tusharb86]

@peterlewis Thanks for fixing this! Adding an "alpha" version for 7zip in a similar way to how VS Code handles the "Insiders" build was a great idea. 👍

❯ winget search 7zip
Name         Id               Version         Matched
-----------------------------------------------------------
7Zip         7zip.7zip        19.0.0          Moniker: 7zip
7Zip-zstd    mcmilk.7zip-zstd 19.00-v1.4.5-R2 Tag: 7zip
7Zip - Alpha 7zip.7zipAlpha   20.0.2-alpha    Tag: 7zip

❯ winget search vscode
Name                          Id                                 Version            Matched
------------------------------------------------------------------------------------------------------------
Visual Studio Code            Microsoft.VisualStudioCode         1.49.1.58bb7b2331  Moniker: vscode
Visual Studio Code - Insiders Microsoft.VisualStudioCodeInsiders 1.50.14.635cfbcd0f Moniker: vscode-insiders

[peterlewis]

@peterlewis Thanks for fixing this! Adding an "alpha" version for 7zip in a similar way to how VS Code handles the "Insiders" build was a great idea. 👍

No worries, happy to help! I can't take a huge amount of credit for it, though. I've just installed GitHub Desktop and it appears that it's also apparently used to differentiate between GitHub.GitHubDesktop and GitHub.GitHubDesktopBeta! 😄

[Touratica]

The way I would go about this would be making winget ignore any manifest with beta/alpha/prerelease in its version by default, unless the user explicitly used something like an --allow-pre-releases flag in the command to install/upgrade.
This wouldn't solve the issue of multiple channels (like a lts or latest), but would avoid things like installing an alpha version of 7-Zip by default.

[iDolmatov]

I think it's possible to implement the build type (LTSC, Beta, Alfa, Stable, early) in the manifest. It is necessary to determine how many such groups are needed.
Example:

Chrome browser provides 5 channels: Stable, Extended stable, Beta, Dev, and Canary.

https://support.google.com/chrome/a/answer/9027636?hl=en

Then, at the settings level, implement the assignment of a version check relative to the channel.

 "channel": {
        "appname": channel_name
    },

This option is not excluded:
There is no universal set of channel names, only a basic list.
The search and show packages commands have an additional "--channel" parameter. When used, the available channels for the packages found are displayed.
The user can manually write the settings or use the channel selection command "--select-channel", "--verbose-channel" (write settings or one-time selection).

In the directory itself, only stable releases can exist with a manifest without a channel, and other flavors must contain the channel name.
To facilitate the process of checking versions and channels (especially when there are many of them), pull-request should be supplemented with an automatic mechanism that will generate a common manifest with a list of channels and versions related to them.

I understand that I wrote my thoughts rather scattered. I think the main idea in creating a comprehensive structure is clear.