Redesign the update checker

[verm]

The current update checker design is very broken.

Apart from the code causing crashes on all platforms but Windows, the file format is inflexible and needs redesigning.

[verm]

crash log.

[nielsm]

Since this amounts to an almost complete rewrite (since the architecture of the old checker can't work on anything but Windows) I think a little review of the update advisory policy.

We need three or four kinds of upgrade targets. Currently there are two.

The current two targets:

• Release version
• Development version

The targets need to be expanded to these four:

• Stable bugfix version (such as 2.1.7 -> 2.1.8)
• Stable major version (such as 2.1.9 -> 2.2.0)
• Unstable in same branch
• Unstable in newer branch

Furthermore, for unstable releases we need to handle some platform differences. A Windows user running a build done by someone else won't care about a tarball and a Mac user won't care about a new Windows binary.

Currently we have a latest.txt file format based on lines with four fields:

type;version;url;description

• type can be release or svn. In this scheme, svn means a Windows binary built from an unstable SVN checkout, and assumes no branches.
• version depends on whether it's a release or development version. For development versions, it's simply an SVN revision number. For release versions it's a dotted version number, a dash, and the SVN revision number the version was built from.
• url is where the user is pointed to read further about and download the new version.
• description is a short text displayed in the GUI.

The current/old code should skip lines that have anything else than 4 fields, and lines where type isn't svn or release meaning we can easily extend the format that way for describing development releases. We still want old releases to be able to detect a major new release so we must stay compatible for release lines, but old unstable releases should probably only detect the latest stable release.

There is an important policy question. Consider this hypothetical case: We release 2.1.9. Then 2.2.0 is finished and released. Some people don't want to do a major upgrade for some reason. A grave bug in 2.1.9 is found, and we produce a 2.1.10 bugfix release, so now there's 2.1.10 newer than 2.2.0, with a higher revision number. Which do we tell 2.1.9 users about?

[verm]

All of this makes sense.

As far as the last paragraph goes: notify for both, we won't be releasing that often and those that leave version checkers enabled don't mind the odd message or three a month.

[nielsm]

See Technical/UpdateChecker for what will be implemented.

[nielsm]

This is impossible to do without new strings.

I am going to introduce new strings in this regardless of string freeze. Translators who don't mind a few more strings can translate them, but having these few strings untranslated won't be a major problem. (I have seen far higher profile software release versions with horribly lacking translations, Aegisub is a miracle in comparison.)

Even if the user barely understands English, the UI will still be easy to understand I believe: If there are no updates available, the user will see nothing. If there are updates, the user will see a clickable URL. The surrounding text is less important: There is a URL you can click.

[nielsm]

(In [3906]) Entirely new version/update checker. Updates #1071.
To do: Disable the menu item while the update checker thread is running, possibly some more polish.

[nielsm]

(In [3909]) Make automatic checks for updates happen at most once every 7 days. Add option to toggle automatic update checks in the update checking result dialogue. Make auto-check option in Options dialogue available on all platforms.
Updates #1071.

[nielsm]

(In [3910]) Fix bug with update checker window being open preventing Aegisub from properly closing.
Updates #1071.

[nielsm]

(In [3911]) Disable the "Check for updates" menu item while the update checker is working.
Updates #1071.

[nielsm]

(In [3912]) Change to store "next check" time instead of "last check" time. After each check, set "next check" to now + one hour. If an update is found, the user is now offered a "remind me again in a week" button, which sets the next check time to today + 7 days.
Updates #1071.

[nielsm]

There is some kind of problem with the new checker on non-Windows platforms, that causes the UI to become unresponsive, despite the checker doing all work in a separate thread.
It's not a bug I have a chance of looking into.

However I do think it sounds fishy that a check that takes about 0.2 seconds should cause the UI to become unresponsive for a long time. (By the time the results dialogue pops up the checking thread is already done with its work and shutting down if not already deallocated.)

[verm]

Alright I was mistaken the first time it's not a slowdown, Aegisub uses 100% of the system cpu it appears to be caught in a loop, I'll investigate in a bit.

[nielsm]

(In [3932]) Change OS X name and version grabbing code, now it should report it correctly.
It's kinda ugly but shouldn't pose a problem, and we'll also get patchlevel along.
Updates #1071.

[nielsm]

(In [3933]) Work around wx bug causing update checker to choke on zero-byte data files.
Updates #1071.

Said wx bug @  http://trac.wxwidgets.org/ticket/11596

[nielsm]

(In [3935]) Fix operator precedence-induced bug in OS X version reporting. Updates #1071.

[nielsm]

It looks like everything works correctly now.