Ugrading Apps that support multiple versions installed.

[denelon]

Several packages support side by side installation. This presents challenges with the upgrade scenario. As of the 1.0 builds, the Windows Package Manager attempts to upgrade any lower version to the latest (or specified version).

Note: Assume proper semantic versioning for the examples below.

Assume package foo supports side by side installation for all major versions.
Assume the user has version 1.0 and version 2.0 installed.

If the latest version in the repository is 2.1, when the user performs winget upgrade foo, the expected behavior would be for version 2.0 to be upgraded to version 2.1, and version 1.0 is left alone.

At this point, the user would have:

Two versions of food installed; foo version 1.0 and foo version 2.1.

If a new version 1.1 of foo is released, the user would wish to see this when they run winget upgrade.

If they were to run winget upgrade foo, they would expect version 1.0 to be upgraded to version 1.1.

This discussion is intended to support proposals for how this could be accomplished.

Related PR:
#16070 (comment)

[vedantmgoyal9]

for package foo:
  we can compare major versions (x.0 and y.0) and then upgrade the packages.
but in the case of python:
  we have to go a bit deeper 3.8.x and 3.8.y

I mean to say that winget can run a loop and check for available versions in the repository. If it finds multiple versions with a major version, it should go a level deep (minor version) and check again. If it still finds multiple versions, it should go more deep (patch version) and this continues till it finds different versions.

[vedantmgoyal9]

I hope something like this would help to accomplish this task.

[denelon]

The package manager already does this with respect to determining latest. The challenge is when there is a valid reason to have multiple versions installed. We may need to augment the manifest for packages with this kind of behavior. In the example of python, users would potentially want more than one version installed. There needs to be a way to indicate which versions represent a true upgrade from some set of previous versions.

Python 3.8.1 might be considered and upgrade for 3.8, but not for anything below 3.8.

[jedieaston]

This is not a solution, but just wanted to put this here as prior art: https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept.

NPM forces semantic versioning, and allows the user of the package to say whether they want to accept all updates, only patch (so the third number), or minor and patch updates. I wonder if there’s some way we could do math or a survey on the repo to determine how many apps use semver and therefore would work if the client implemented something like this. Python, .NET, and Node all do I know.

Also, it’s worth nothing that the multiple minor versions of Python issue was fixed in Debian/RHEL (and their derivatives) by having separate packages for every minor release (python3.7, python3.8, python3.9) with a pointer package (python3) that pointed to the newest minor version. If you installed python3, you opt in to minor version updates, whereas with the other packages you only get patches. I know that pointer packages are being resisted, but that’s how they solved it.

[denelon]

That works when packages use semantic versioning. Sadly, many don't. Maybe it would make sense to have additional metadata about how an application is versioned. This would also help with package pinning. Keeping a pointer "current" would likely also require this kind of knowledge. As we move into the v1.1 schema it will be possible to have a package with a "marketing" version, and an application version (how it's reported in Apps & Features).

I think this topic will also require some additional fields in the manifest schema (and subsequently the REST schema).

[vedantmgoyal9]

$oldVersions = @()

do {
$readinput = Read-Host "Please enter installed versions" # winget will detect installed versions of the software on pc
if ($readinput -ne '') {$oldVersions += $readinput}
} until ($readinput -eq '') # when input is null, exit loop

$newVersion = (Read-Host "Please enter new version").Split('.') # new update available
# begin: logic
Foreach ($oldVersion in $oldVersions | ForEach-Object {$_.ToString()}) {
    $oldVersionArray = $oldVersion.Split('.')
    for ($i=1; $i -le $newVersion.Count; $i++) {
        if ($oldVersionArray[$i] -eq $newVersion[$i]) {
            $VersionToBeUpdated = $oldVersion
        }
    }
}
# end: logic
Write-Host "WinGet will upgrade`: $VersionToBeUpdated"

@denelon The core logic that this script uses to check the version to be updated, I was thinking of a similar logic to be implemented in winget.

[vedantmgoyal9]

@jedieaston @denelon I think it should work. I had tested it for multiple cases and it was returning the correct version which will be upgraded.

An additional field like MultipleVersionsSuported: <true|false> can be included in the manifest schema v1.1. If the value is true, winget will attempt to run the logic check for the application version which has to be upgraded.

[vedantmgoyal9]

@denelon It has been a long time and it looks like you've missed this. I've prepared a logic and I think it can work in this case.

[vedantmgoyal9]

@jedieaston running the above script:

I think this is what we want to do. We can use similar logic in winget-cli and when MultipleVersionsSuported is set to true and the user is doing an upgrade, winget would upgrade apps side-by-side.

[jedieaston]

What if someone wants to have 3.1 and 3.2? Or what if a app uses a non semver scheme (like Unity)?

I think we (or Microsoft or whoever) need to discuss this and come up with something that will work for all sorts of things.