Add a new release notify feature in MuseScore

Your question is answered at [[nodetitle:Comparison of stable, prerelease, and nightly builds]]

You can follow the Twitter or Facebook (see the links in the footer of the page) to be notified when there is a new prerelease. Regarding new releases, subscribe on the mailing list on the [[nodetitle:download]] page.

We are considering an auto update feature for MuseScore, but it's still in the thinking phase. However, it might be great if we can roll this out for the next release. This way, people will be notified when there is a new release when opening MuseScore. So, I'll change this issue to track the development of the auto update feature.

Tato, the fixes usually indicate the "revision" number (often abbreviated to "r"). To see what revision number you are using look at Help > About in MuseScore. You can also look at the dates. Version 0.9.5 stable was released in September 2009.

As of this morning, it is possible to follow the nightly builds via RSS feed

First investigation results by lasconic:

- Looking for OS QT apps which do auto update checking. VLC player looks like the best option to look in. VLC does a GET http://update.videolan.org/vlc/status-win-x86 which returns a static text file.

- FileZilla, also OS, does an https check GET http://update.filezilla-project.org/updatecheck.php?platform=i586-pc-mingw32msvc&version=3.1.6&osversion=5.1&beta=1 and it's apparently php processed.

I prefer the VLC way, because the static file does not need to be served by a web server, but rather by a file server. The file server stats can be used to harvest statistics. One thing that we could do better than VLC is use at least some XML instead of a raw file.

Some more info: Mozilla (Firefox) uses manifests for it's addons. It explains some interesting facts such as: It is strongly recommended that the updateURL be an HTTPS (secure) link. Non-secure update URLs can be hijacked by a malicious update.rdf file, enabling malware to infiltrate the user's computer.

Compare this to the VLC notify system and admit it's a huge difference. A little beyond our capabilities I think. More later.

I've never had a need to purchase it myself, but I've heard that SSL is much cheaper these days. Adblock Plus recently started using StartCom certificates .

As a first step, MuseScore could check for update on Windows and Mac. On linux, package managers should handle the job.
To start with, just a plain "easy" check for update.

• no download of the new version
• no installation and restart

I propose to put somewhere on a server, a xml file per OS and per release type: stable, pre (and maybe nightly ?).
This file will be access though HTTP. This file will just be parsed, value checked and displayed, so no binary execution and less security concern. HTTPS is not necessary here.

So 4 files for the moment

• update_win_stable.xml
• update_win_pre.xml
• update_mac_stable.xml
• update_win_pre.xml

This file should contain:

• The version (ex:0.9.6)
• The revision (ex: 2564)
• Release date
• Download url
• Information url
• Description to be displayed

By default MuseScore on Mac and Windows will check on every startup if there is a newer version available.
A new preferences panel could be added to let users disable this feature and maybe set a proxy.

Possible enhancements:
- Check only every X days
- Don't check if a new version has been found
- Ask user on first launch if they want to check for update or not
- Of course auto download, installation, restart etc ...

wow, me likey!!!!!!!!!!!
I agree!!!! all this is super cool!!!!!
Go for the best method guys, don't settle for anything less, why not be cool?

The files can be stored on amazon s3 using the cloudfront cdn so it is served in the fastest possible way and will always be available (i.e. not connected with the musescore.org webserver). We could use a dedicated subdomain like update.musescore.org.

I see reasons to add a nightly update file as well.

The file elements look fine. While version, revision, release date and download url are language independent, information url and description might be internationalized. Example:

• information url: pointing to the translated release notes
• description: localized information

I don't want to over engineer this right from the start, but it could be done in a similar way as is done for the handbook checking.

[http://www.musescore.org/fr/...]


The files can be stored on amazon s3 using the cloudfront cdn so it is served in the fastest possible way and will always be available (i.e. not connected with the musescore.org webserver). We could use a dedicated subdomain like update.musescore.org.

I see reasons to add a nightly update file as well.

The file elements look fine. While version, revision, release date and download url are language independent, information url and description might be internationalized. Example:

• information url: pointing to the translated release notes
• description: localized information

I don't want to over engineer this right from the start, but it could be done in a similar way as is done for the handbook checking.

<information><url locale="fr">[http://www.musescore.org/fr/...]</url><information>


Some of my concerns:

Frequency

A check for updates every start-up seems excessive. For stable releases once a week should be plenty. For prereleases maybe every one or two days. The option to turn off update check is just as important.

Start-up speed

The update check should be coded so that it doesn't increase start-up time in any way. If a network request is initiated at start-up then start-up should not wait for a response before continuing. Better yet wait till after start-up to make the network request. If a dialog appears requiring user input, it should not pause the start-up sequence.

Annoyance

The notification of a new update should be at the very beginning of the session (when the user first starts MuseScore) or the very end (when the user closes). The notice should not be excessively repetitive. Particularly for stable releases it is important that the user upgrades on their own schedule. For example I wouldn't recommend upgrading in the middle of a big project or at a particularly busy moment.

For web browsers and operating systems the need to constantly update is critical for security purposes. For document-based software stability is king and updates are less critical. Of course they may find that the newer version is more stable, so the update checker informs users that there is a better tool than they are currently using.

To reveal my bias I should mention that with most other software I turn the update checkers off. I only check for updates manually (on my own time).

My preliminary answers which might need backing by lasconic:

The frequency can be set by the user, either during the installation procedure, either in the preferences section. We can default it to e.g. 2 weeks up to one month.

The startup speed should not be affected since it will run in a different thread.

The annoyance factor should be non existent if we give the user the right control and guidance. The user can decide to disable the auto update check all together and only check when he wishes to. After all, we are implementing this to make life easier for all of us: (i) eliminate the annoyance factor when a user bumps into a crash which is solved in a newer version, (ii) eliminate the annoyance at the side of MuseScore support when having to tell the user that the bug has been fixed in a newer version and upgrading is advised.

An update check flow proposal:

• Installation: The installation wizard should have a step where the user is asked whether to opt-out from the auto update check. At the same time it should inform the user that his privacy guaranteed. When auto update is left enabled, the next step should check whether there is a new update. If so, advise the user to download the newer release. Storing
• First time startup: If auto update is enabled and the auto update time interval has passed the previous check, do a new check.
• Normal startup: Same as first time startup.
• Triggered update check: Menu > Help > Check for updates.

The update check will be especially interesting for development purposes. Since MuseScore does not have any software unit testing, the project currently limited to developer based testing only. This should make testing much more convenient.

Doing things in the installation is not possible for the moment. There is no simple way to pass data from the installer to the software. Of course it can be done with a file, the registry etc... Moreover, there is no installer on Mac.

I added some code in r2571.
There is no annoyance, checking the file through HTTP is asynchronous. I tested without internet connection and it works ok. No slowdown.
Manual check is possible. From Menu > Help > Check for updates.
There is a new "Update" preference panel with a checkbox "check for update on startup".
There is nothing done for frequency yet. So, there is no check on startup for the moment to avoid any annoyance. The code to do it is commented on line 1931 and 1932.

Another reason why I commented these two lines, for the moment the only way to test is with nightlies.
The file is http://update.musescore.org/update_win_nightly.xml
As nighlies are built every night, I guess it should be good to have an semi automated way to make this file and upload it to update.musescore.com.

The code is a free adaptation of http://www-sop.inria.fr/dream/blog/2009/07/qt-application-updates-check…
Not sure it's 100% C++ & Qt compliant so a review is welcome.

It should be fairly easy to incorporate the update xml into the Windows nightly build process. It already updates an HTML and RSS file automatically. Can it be uploaded via FTP?

At the moment the moment it looks like an error occurs with the xml file (or I don't understand it).

<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>1D05C47A538454FE</RequestId>
−
<HostId>
EO9HbMdDZQgAxgg6kvmvKKcSPS7T+MV865uLNeVSzyFducG6MfjFgloOV+AMTU4W
</HostId>
</Error>

I uploaded the file. It should be ok now. The files can be updated via a control panel on musescore.org, so no hassle with uploading. The control panel is being developed as we speak.

In order to couple it with the nightly build process, a url will be available which simply accepts a GET request with the right parameters in order to be updated.

A GET or POST request might work. I'd have to look up how a Python script can authenticate over HTTP.

The upgrade on Windows from nightly r.2572 to nightly r.2574 worked for me. This time I manually updated the information using the control panel.

Great!!

Very nice if it works for nightlies!

Next step is to have a preference to choose the frequency of the check.
Here is a proposition

• Every day (default for nightly)
• Every 3 days
• Every week
• Every 3 weeks (default for prerelease)
• Every month
• Every 3 months (default for stable)
• Never

Obviously the date of last check needs to be stored. I'm not sure if it's better to use the preferences QSettings mechanism or to write a new file similar to sessions.txt. Any opinion?

A little bit OT, are the python scripts for nightlies versioned somewhere? It could be of interest for someone to make something similar for Mac (and maybe a portable version for Linux).

The frequency looks good, but I would change 3 to 2.

Using the QSettings mechanism would mean it gets reseted when using -F right? Seems ok to me, but I'm not going to call on this matter.

I would recommend shorter default intervals for the prerelease and stable update checks. For example if it happens to checks just before a release it would be a full 3 months before it informs the user of a new stable release.

Maybe every few days for prerelease and every month for stable releases?

Most of the build modifications were written with Windows batch scripts so they would not be cross platform. These source files are included with every nightly build. The Python upload script for the nightly builds is not public because the password is hard coded in. I could move the sensitive information to a separate file if others want it in the repository.

in r2617, there is a new preference to choose the frequency of automatic update checking.
The following is implemented:

• Every day (default for nightly)
• Every 3 days
• Every week (default for prerelease)
• Every 2 weeks
• Every month (default for stable)
• Every 2 months
• Never (replace the previous checkbox)

Checking for update manually reset the "timer".
I tested a little bit on windows by changing the system time. It seems to work. More tests will be needed.
The check on startup is now uncommented.

If Help > Check for Updates does not find updates then it should probably inform the user with a dialog. Otherwise it looks like nothing happened. Of course the "No Updates" dialog shouldn't appear during automatic checks at startup. The dialog should only be for manual checks via the menu item.

"No update available" dialog has been added in r2622.

Any thoughts on whether the prereleases should automatically update to the release candidates and eventually the final release or whether the prereleases should stay on their own track?

My personal feeling is that prereleases should follow the alpha - beta - RC and final release track. After that, it starts again with the next prerelease.

On the implementation side, it does not matter.
A nightly is looking for nightly file, a prerelease for prerelease etc ...
The important thing is what we put in the xml files on the server.

Of course updating a nightly to a stable version will stop the update cycle.

I assume it is safe to mark this as fixed. The New release notify feature is included with 0.9.6 stable.

Automatically closed -- issue fixed for 2 weeks with no activity.