I spent more quality time trying to understand Microsoft's installer options :) Here is a summary:
Windows supports two different packaging formats. The old MSI and the new MSIX. We currently produce both for Juliaup.
For each packaging format, Windows supports multiple ways of installing and updating them. Here are the options.
For MSIX:
- The Windows Store. If it works, the best option, as it auto-updates, Microsoft pays for the download traffic, we get stats etc. Users can initiate this install in two ways: via the Windows Store app (and we could add links to the homepage that take them there directly) or via
winget install --name Julia --id 9NJNWW8PVKMN -e -s msstore. OR we can also add the store source to the winget community repository. More on that later.
- App Installer. We host the MSIX files ourselves, and we host an
appinstaller file that is a XML file with links to the latest MSIX installer files. App installer is a piece of Windows that can install these appinstaller files, and then also auto-updates them in the background (which is nice!). No winget integration for this whatsoever.
winget via the community repository. We host the MSIX files, and the community repository points to those installers. Command would be winget install Julialang.Julia (I think). Updates in this scenario are via winget and manual, i.e. users have to write winget upgrade to get a new Juliaup version. I believe winget is getting an optional feature for periodic auto-updates, but it seems to be opt-in.
- There are even more options (MULTIPLE!!), but I don't think they are super relevant for us. Essentially you can manually download the MSIX packages and then provision them on a machine so that they are available for each users and stuff like that. All via PowerShell.
For MSI:
5) Traditional, you download, double click, it installs. No auto-update, though.
6) Via winget. In that case, winget would handle updates. They wouldn't be automatic, but via winget upgrade, same story as above.
So, first of all, clearly this is madness...
Ok, here is more about the winget community repo. So this is like our general registry, where folks can register installers that winget then exposes to users. One can register multiple installers per name. So we could for example register Julialang.Julia, and then list the store, the MSIX and the MSI installers all in there. Supposedly winget will then pick the "best" installer, depending on what is allowed on the user system.
The community repo already has Julialang.Julia and Julialang.Juliaup registered. My plan at the moment is to initially try to "take over" Julialang.Juliaup and register the store, the MSIX and the MSI installer under that name and then we can test it a bit. The main thing that is really a shame is that we can't put the app installer version (option 2) in there, i.e. the only thing that we are going to expose that way that truly auto-updates this way is the store version... But hey, lets see.
And then, at some point I think we should switch Julialang.Julia over to install Juliaup. At the moment Julialang.Julia is getting folks the legacy GUI installers for a specific Julia version, and I think we should try to take that out of the winget story.
If anyone has thoughts, go forth!
I spent more quality time trying to understand Microsoft's installer options :) Here is a summary:
Windows supports two different packaging formats. The old MSI and the new MSIX. We currently produce both for Juliaup.
For each packaging format, Windows supports multiple ways of installing and updating them. Here are the options.
For MSIX:
winget install --name Julia --id 9NJNWW8PVKMN -e -s msstore. OR we can also add the store source to the winget community repository. More on that later.appinstallerfile that is a XML file with links to the latest MSIX installer files. App installer is a piece of Windows that can install these appinstaller files, and then also auto-updates them in the background (which is nice!). Nowingetintegration for this whatsoever.wingetvia the community repository. We host the MSIX files, and the community repository points to those installers. Command would bewinget install Julialang.Julia(I think). Updates in this scenario are viawingetand manual, i.e. users have to writewinget upgradeto get a new Juliaup version. I believewingetis getting an optional feature for periodic auto-updates, but it seems to be opt-in.For MSI:
5) Traditional, you download, double click, it installs. No auto-update, though.
6) Via
winget. In that case,wingetwould handle updates. They wouldn't be automatic, but viawinget upgrade, same story as above.So, first of all, clearly this is madness...
Ok, here is more about the winget community repo. So this is like our general registry, where folks can register installers that
wingetthen exposes to users. One can register multiple installers per name. So we could for example registerJulialang.Julia, and then list the store, the MSIX and the MSI installers all in there. Supposedlywingetwill then pick the "best" installer, depending on what is allowed on the user system.The community repo already has
Julialang.JuliaandJulialang.Juliaupregistered. My plan at the moment is to initially try to "take over"Julialang.Juliaupand register the store, the MSIX and the MSI installer under that name and then we can test it a bit. The main thing that is really a shame is that we can't put the app installer version (option 2) in there, i.e. the only thing that we are going to expose that way that truly auto-updates this way is the store version... But hey, lets see.And then, at some point I think we should switch
Julialang.Juliaover to install Juliaup. At the momentJulialang.Juliais getting folks the legacy GUI installers for a specific Julia version, and I think we should try to take that out of the winget story.If anyone has thoughts, go forth!