Confirm
3,816
edits
Changes
New page: These questions and answers are from a conversation with Paul Reed, one of the build engineers at Mozilla. The questions came from our calendar community members and I think this will hel...
These questions and answers are from a conversation with Paul Reed, one of the build engineers at Mozilla. The questions came from our calendar community members and I think this will help to illustrate how the update process works.
== General ==
Automatic Update Service (AUS) is a system that updates Mozilla binaries by either supplying a complete download of a build or a partial diff from build version x to build version y. There are different channels that these updates can be dispatched to. For example, if you are on the release channel then you are dispatched only builds that have the "release" channel bit set. This means you only get the major releases. However, if you are on the "nightly" channel, then your build will update every day, once the new nightly builds are completed.
The "complete" download binary files are known as "mars" because this is their file extension. The partial update binaries are referred to as "partials".
The AUS only exists for installable applications, like Sunbird, Firefox, and Thunderbird. AUS does not exist for extensions like Lightning. Lightning can be updated through the extension manager, which uses a separate update process via AMO (link). Therefore, there is no equivalent of a "nightly channel" for Lightning.
== How it works ==
We will consider the release case here. Nightlies are done the same way, just with less business logic to worry about release jumps. For example, when someone installs build x, misses the update to y, and then attempts to update to z is a release jump. For release, these are handled with partials, but for a nightly this problem is simply handled by serving a complete to the user with version x to upgrade them to version z.
When a release is built, the build system itself will generate the MAR files for the complete update. These are stored on FTP with the build. A complete snippet is also generated, and is stored on AUS-staging/OS (TODO: get full path to new server). A script called the Patcher pings the FTP locations, detects the release build and then performs diff's to generate the partial binaries for partial installs back for x number of previous versions. These are also stored on the AUS-Staging server.
When a user runs a build with a previous version, the AUS subsystem pings the AUS server in its preferences. The AUS server responds with an answer that states that either: (1) there is no update available or (2) there is an update available and it sends down the snippet so that the user can be informed about the type and nature of the update. The update is then downloaded and applied to the build.
Usually partial updates are used over complete updates in order to prevent the user from having to download a full build. If for some reason the partial update fails to apply, then a complete build is downloaded and applied in order to make certain that the user lands in a good state.
== Calendar Community Questions and Answers ==
Here are my questions regarding AUS, Update & Build.
1. What are the differences between nightly and release update?
* blah
2. What is Patcher2 needed for? Does it generate a special type of MAR file for release update?
3. Where are the update files for releases stored?
4. Do we have to change some config in Sunbird for release updates?
5. Will the community AUS2 server be in place or have at least an address to configure Sunbird 0.7 in time (September/beginning of October) for the next release update (0.7 -> 0.9)?
6. Public address? How do we access it? Who will maintain it? Do we have community access (-> ause?) Do we have support from #build or mozilla.org if there is an issue? For example who does security updates for the server?
7. Nightly updates (after changing the URL in Sunbird)
9. Special configuration required on the AUS server to support nightly updates? How do we need to configure the tinderbox to upload the update information to the new server? Possibility to hook it up to <http://update-watch.localgho.st/nightly/production/latest/>?
===Update 0.5 release to 0.7 release===
10. We need to use the official AUS server for this. Who will take care of this? How do we create and test the update packages for all platforms x 22 locales? What tools do we need etc.? ...
Update 0.7 -> 0.9 release
Are the tools for package creation and testing public available so that we can do the release ourself? ...
== General ==
Automatic Update Service (AUS) is a system that updates Mozilla binaries by either supplying a complete download of a build or a partial diff from build version x to build version y. There are different channels that these updates can be dispatched to. For example, if you are on the release channel then you are dispatched only builds that have the "release" channel bit set. This means you only get the major releases. However, if you are on the "nightly" channel, then your build will update every day, once the new nightly builds are completed.
The "complete" download binary files are known as "mars" because this is their file extension. The partial update binaries are referred to as "partials".
The AUS only exists for installable applications, like Sunbird, Firefox, and Thunderbird. AUS does not exist for extensions like Lightning. Lightning can be updated through the extension manager, which uses a separate update process via AMO (link). Therefore, there is no equivalent of a "nightly channel" for Lightning.
== How it works ==
We will consider the release case here. Nightlies are done the same way, just with less business logic to worry about release jumps. For example, when someone installs build x, misses the update to y, and then attempts to update to z is a release jump. For release, these are handled with partials, but for a nightly this problem is simply handled by serving a complete to the user with version x to upgrade them to version z.
When a release is built, the build system itself will generate the MAR files for the complete update. These are stored on FTP with the build. A complete snippet is also generated, and is stored on AUS-staging/OS (TODO: get full path to new server). A script called the Patcher pings the FTP locations, detects the release build and then performs diff's to generate the partial binaries for partial installs back for x number of previous versions. These are also stored on the AUS-Staging server.
When a user runs a build with a previous version, the AUS subsystem pings the AUS server in its preferences. The AUS server responds with an answer that states that either: (1) there is no update available or (2) there is an update available and it sends down the snippet so that the user can be informed about the type and nature of the update. The update is then downloaded and applied to the build.
Usually partial updates are used over complete updates in order to prevent the user from having to download a full build. If for some reason the partial update fails to apply, then a complete build is downloaded and applied in order to make certain that the user lands in a good state.
== Calendar Community Questions and Answers ==
Here are my questions regarding AUS, Update & Build.
1. What are the differences between nightly and release update?
* blah
2. What is Patcher2 needed for? Does it generate a special type of MAR file for release update?
3. Where are the update files for releases stored?
4. Do we have to change some config in Sunbird for release updates?
5. Will the community AUS2 server be in place or have at least an address to configure Sunbird 0.7 in time (September/beginning of October) for the next release update (0.7 -> 0.9)?
6. Public address? How do we access it? Who will maintain it? Do we have community access (-> ause?) Do we have support from #build or mozilla.org if there is an issue? For example who does security updates for the server?
7. Nightly updates (after changing the URL in Sunbird)
9. Special configuration required on the AUS server to support nightly updates? How do we need to configure the tinderbox to upload the update information to the new server? Possibility to hook it up to <http://update-watch.localgho.st/nightly/production/latest/>?
===Update 0.5 release to 0.7 release===
10. We need to use the official AUS server for this. Who will take care of this? How do we create and test the update packages for all platforms x 22 locales? What tools do we need etc.? ...
Update 0.7 -> 0.9 release
Are the tools for package creation and testing public available so that we can do the release ourself? ...
