Add auto updater to MuseScore development versions

• Dec 15, 2017 - 12:11
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
MuseScore
Tags
3.0alpha
3.0alpha-06

Here are some thought about getting our development faster to end users for testing purpose but also for stable release and to make support easier.

Current state

MuseScore is currently supported under Windows, Mac and Linux. For stable versions, on Windows, we deliver an MSI package, on Mac a DMG and on Linux an appimage. For nightlies, we deliver a DMG on mac and appimage on Linux, but on Windows we deliver a 7zip file. Users need to manually download new nightlies and on windows, unzip the 7zip file.

Since MuseScore 2.1, we also distribute stable version on Windows via the Windows App Store. On Linux, MuseScore is of course distributed via each distribution package manager. However, on Mac OS, we don't use the Mac App Store. See #53811: Sandbox MuseScore on Mac OSX and https://musescore.org/en/node/52826

For the stable version, we have an update checked in MuseScore. It pings a file stored on S3 where we store the latest version number. MuseScore compares its own version number to the one stored in this file. If it found a new version, it gives a link to the user. It's up to the user to click the link to download MuseScore and install it.
This mechanism is not implemented for nightlies right now. The server side is lacking.

Development (and stable) versions on Mac and Linux are built automatically on Travis-CI for each new commit. However, Windows builds happen on a virtual machine hosted by Zurich University of the Arts. This machine is going down with every Windows update, it's slow and a burden to administer.
See our development infrastructure

Problem

For testers, it's a pain to check for new development versions. They need to visit our download page and find the right package. For development purpose, it's crucial to get feedback for the latest version, and not an old dev version. An auto updater would solve part of this problem if it would check for new version, upload and ask them to install the latest version.

We work hard on each release and we want people to get the greatest latest as soon as possible. At least we want them to have an easier way to download and install the newest version. For MuseScore 3.0, we hope to be able to create point releases (3.1, 3.2 etc...) more often. Here again, an auto updater would help and having MuseScore in the Mac App Store too (that's another issue).

Specification

Update checker

First we need a more reliable way to generate Windows versions. The build process needs to be move to Appveyor. See #106071: Migrate MuseScore windows nightlies from a dedicated server to appveyor
Then, we should probably implement our current update checker for Windows development versions.

Auto update

Auto update would first check if there is a new version. Then it would download the new version and ask the user if he would like to install. Ideally, it would then proceed with the install and restart MuseScore.

For stable version, using the Windows App store and the Mac App store would provide auto update for free. Unfortunately, both stores don't have a alpha/beta channel like it's done for mobile app (AFAIK)

Task list

First stage (Quickest approach)

Second stage (less clear how long it will take...)

  • Investigate cross platform libraries for auto update (QtSparkle,
    Fervor, Update Installer, QSimpleUpdater...)
  • Investigate how other open source applications are doing it (Firefox, Chromium, Telegram, VLC etc...)
  • Investigate UAC problems on Windows.
  • Investigate server requirements for auto update
  • Implement server side and build system changes
  • Implement auto update on Windows development versions and test
  • Implement auto update on Mac development version and test
  • Implement auto update on Linux development version and test

Comments

• Aug 28, 2018 - 10:59
Status (old) closed ⇒ active
Status closed ⇒ active

Reopen to investigate second step. Now that we have update checker working, we want to have the ability to download the install package, close MuseScore, install the update and restart the new MuseScore. If possible on all platforms, and with minimal effort and high maintainability... If we download the package and install it ourself, we need better security too, so we don't install garbage on user's computer.

Investigate how other open source applications are doing it

Telegram

  • 100% custom code, a different binary per platform
  • Telegram desktop is GPLv3, MuseScore is GPLv2... we can't copy their code anyway
  • Security has been considered

VLC

Investigate cross platform libraries for auto update

QtSparkle

Fervor

Update Installer

  • last activity 5 months ago, 174 stars, 36 forks
  • Can download and install. Use an executable to download, install and restart the main app. Executable needs to be signed.
  • Need specific packaging for the updates

QSimpleUpdater

  • last activity less than a month ago, 148 starts, 46 forks
  • Only download, no install

Non crossplatform

Reply

• Aug 31, 2018 - 21:42

The most viable way for now seems to be Sparkle/WinSparkle. I started to investigate Sparkle on MacOS. It needs to be integrated in our build and it requires changes to our CI. An important limitation is that it doesn't support sandboxed app yet. Sandboxing among other things is required for the Mac AppStore, so we need to make sure autoupdate is something we can build optionally. Also we don't want autoupdate for developers so the option should be off by default for them.

On the server side, we will need update.musescore.org or another domain if we want to change to support HTTPS. It's not the case right now for update.musescore.org which is hosted on S3. We will also need to sign the app, and I believe we do it already. We could also sign the resulting package with DSA signature provided by Sparkle, it's not yet mandatory but it could become. In this case, we will need to inject the keys in travis...

Last point, the appcast file. For each update, we will need to update the appcast.xml file with info about the update. A script needs to be written or found in order to generate new entries in this file. I wouldn't use delta update right now.

I would suggest to create an appcast at https://update.musescore.org/devel/3/macos/appcast.xml
With such a scheme, we can have an appcast for stable version and for development versions. We can also stop publishing update when we switch to MuseScore 4 if we want. And of course, we can use a different url for windows.

I didn't try winsparkle yet.

Reply

• Sep 4, 2018 - 00:37

Hi guys
Speaking as an end user, testing updating MuseScore 3 development under OSX is fairly straightforward. I understand your trying to automate the entire process, an admirable goal. Presently it is just a few clicks and roll through's with the buffer on a terminal gets things downloaded compiled and installed. What isn't so immediate to me at least, is what to test for. Sometimes it is obvious by the name of the code modules changed sometimes it isn't.

Thanks for making it so easy!

Reply

• Sep 25, 2018 - 10:55
Status (old) fixed ⇒ active
Status fixed ⇒ active

Lol, it is side-effect of the webhook :) It takes all branches existing in MuseScore repo into account.

Reply