wiki:Technical/UpdateChecker/OriginalDesign

Legacy update checker design

Version 2.1.7 and earlier use the latest.txt format, which is as following:

type;version;url;description
  • type is either svn or release.
    • svn: The release described is an unstable Windows binary release. This release is only interesting if the user is already running an unstable release.
    • release: The release is a stable Windows binary release. This is interesting for everyone.
  • version depends on type.
    • svn: The version is an SVN revision number, the newer binary was built from. No branch information is known.
    • release: The version is a decimal number, a dash, and an SVN revision number. For example, 2.2-3131 would have been suitable for version 2.1.7. The part before the dash is read as a double, and compared to the current build's version number which is also converted to a double. The SVN revision number is used if the user is currently running an unstable version, to compare against.
  • url is an URL the user is pointed to for the update.
  • description is a short textual description displayed to the user.

This format is not very flexible, as it does not support multiple branches and does not take multiple platforms into account.

Because we may have misunderstood it ourselves up until and including the 2.1.7 release, it has been broken and doesn't point newer nersions to the correct locations, or may not even be detected.

This file has been located at the following URLs:

The current file at files.aegisub.net has the following two lines:

release;2.1.3-2429;http://www.aegisub.net/2008/10/aegisub-213-released.html;Aegisub 2.1.3a Release Preview r2429 build - New default audio/video provider, audio stability issues, several general fixes.
svn;2429;http://www.aegisub.net/2008/10/aegisub-213-released.html;Aegisub 2.1.3a Release Preview r2429 build - New default audio/video provider, audio stability issues, several general fixes.

Notice that the version field of the release line does not conform to the parsed format. It will most likely be parsed as version 2.1, which both 2.1.6 and 2.1.7 consider themselves as too, because those two numbers also parse to 2.1 as doubles. As a result, Aegisub 2.1.6 sees that line as describing the same release as itself.

The solution will be to, when we release 2.1.8, change all known locations of latest.txt to describe an imaginary version 2.2-4000 or similar, which all known versions should consider as newer. In addition, 2.1.8 should change to a new format for describing update paths.