3,035
edits
AUS:Manual: Difference between revisions
→Version
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 31: | Line 31: | ||
= Incoming URIs = | = Incoming URIs = | ||
A request from an actual Firefox 2.0.0. | A request from an actual Firefox 2.0.0.2 nightly client on an Intel Mac would look like this: | ||
https://aus2.mozilla.org/update | https://aus2.mozilla.org/update | ||
| Line 90: | Line 90: | ||
== Product == | == Product == | ||
/Firefox | |||
The product is straightforward. It tells AUS where to look for update information in its data source. | |||
This is typically the name of the product with the first letter capitalized. | |||
== Version == | == Version == | ||
/2.0.0.2pre | |||
This specifies which version of our product is requesting an update. For releases, there is a 1:1 relationship between the incoming version and the data source for that version. | |||
For nightlies, product versions are mapped onto branches. Updates for all versions for that branch are determined by looking at the same data set. The %CHANNEL% has to be "nightly" in order to trigger this logic. For example, an incoming version could be 1.5.0.2, but the update would come from the 1.5.0.x source directory. | |||
Versions will pretty much always be similar to versions found in a given product's releases/ directory. | |||
== Build == | |||
/2007012207 | |||
Build id's date the client. Originally AUS was designed to only offer updates to clients who had build IDs that were older than the "latest" update available to AUS. | |||
This was changed when Firefox 2.0 was released, because in order to update 1.5.0.9 clients to 2.0 this rule had to be broken -- the release build for 1.5.0.9 was newer than the release build for 2.0. See [https://bugzilla.mozilla.org/show_bug.cgi?id=357892 bug 357892]. | |||
The logic was then limited to non-release channels (nightly channels). Currently the build id is used solely to make sure that nightly testers are always updated to the latest build. It is used to compare the latest available update with what the client currently is, and offers the update only if the available update is newer. | |||
== Platform == | == Platform == | ||
/Darwin_Universal-gcc3 | |||
Platform is straightforward like product is. Once product and version is determined, the platform is needed to specify where to find update information for any given client. There is no additional logic attached to the platform value. | |||
== Locale == | == Locale == | ||
/en-US | |||
Locale is straightforward. There is no additional logic attached to it. | |||
== Channel == | == Channel == | ||
/nightly | |||
/release | |||
Channel was added with update version 1. Above all, it is used to separate releases from the rest of AUS. | |||
Some other channel examples: | |||
/betatest | |||
/releasetest | |||
In addition to making sure official releases are identified by the "release" channel, they also provide a way to test Software Update prior to releases. By using the "betatest" and "releasetest" channels, we can stage updates and verify that they work properly. | |||
A special channel is the "nightly" channel. This triggers all nightly logic. Nightly logic is special because it tells AUS to offer only the latest nightly build to the requesting client. | |||
= AUS Use Cases = | = AUS Use Cases = | ||