AUS:patcher3

Deprecated by work on Balrog.

What does patcher2 do ?

The config file specifies

• a <current-update> block - a pair of releases to build a partial update between, with associated URLs, channels, and properties that will end up in the snippets offered to the app
• a series of past-update definitions, which list previous update versions and channels
• a <release> block for each release on the 'stable branch', giving their platform-buildID pairs, a list of locales, file locations

patcher2 can

• download the source and build all the tools it needs generate partial updates (it downloads way more than it needs)
• generate an update 'graph' (more info needed)
• download complete mar files and
  • generate a manifest for the fast patch generator (make_incremental_updates.py) and call out to it, OR
  • generate partial updates directly (no longer used)
• generate snippet files for the <current-update> and all the past-update's, using the mar files and the update graph

The major problems with it are

• the snippets duplicate a lot of information, ie all the 3.5.x releases from b1 to 3.5.10 update German Mac to the same build, partial only from 3.5.10 to 3.5.11. It's slow to generate and copy these files around
• we should support the new properties Rob Strong added (538331,530872)
• it doesn't handle locales that are dropped for a few releases then come back, the people on the early builds are abandoned
• you can't see the code for the spaghetti and copy-and-paste turds
• it lives in CVS

patcher3 will be glorious

Assuming that all the logic for which updates are offered moves from the snippets into AUS, then patcher3 should be able to

• generate partial updates (at least for win32 after signing)
• 'register' the set of partial & complete updates for the new build with AUS3, as well as other properties on the update (detailsURL etc)

This could well be done as a subset of patcher2, possibly rewritten into python to de-cruftify. The existing config files for major updates (example) would still be fine, we don't need all the past-update lines or the older releases in a stable branch config (they are already registered).

And separately we need a script to

• enable the betatest & releasetest channels for candidate builds (after partials are generated)
• enable the beta channel when a build goes to those testers
• enable the release channel when a release is made to end users (and possibly change the url for the beta channel)
• control throttling and other properties