Right now Balrog only supports /update/3 URLs. We need to support at least /update/4, because that's what Android uses. Not sure about older versions. We might want to wait for the business logic to be reworked before doing this, not sure.

/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml /update/4/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%VERSION%/update.xml Looks like the only difference for /update/4 is the inclusion of the version a second time?

(In reply to Ben Hearsum [:bhearsum] from comment #1) > /update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/ > %OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml > > /update/4/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/ > %OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%VERSION%/update.xml > > Looks like the only difference for /update/4 is the inclusion of the version > a second time? Whoops, that's supposed to be platform version. Turns out that Native Fennec didn't port that part of the update code quite right. Filed bug 861967 on that.

I'm going to be working on this soon.

I started thinking about this again, this time starting from the UI perspective. I don't think we want to splinter rules to have their own silo per query version. Here's an idea about how we can keep them together. * Define the things that each query version can filter on somewhere. * Add "query version" as a filterable thing in the rules table. * When no query version is defined in a rule, all incoming requests will consider that rule. If the rule contains data in a column that that request doesn't have, the rule will not be considered a match. * If a rule defines a query version, only requests using that version will consider the rule. Given that, the implementation could be as simple as adding the query version to the rules table and adjusting the rule matching logic to cope. There's probably some UI changes we'll want to help keep the rules table understandable, perhaps as simple as links that filter by a specific app name, update version, or channel. In the most extreme form, this could mean that version 3 and version 5 share no arguments at all, but still store all of their data in the same table. I can't think of any real example of how he'd end up there, though, as the existing arguments are quite generic. We don't use most of them for b2g at the moment, but we've talked about moving b2g to be more in line with desktop & android update URLs. It's easy to see how product, version, buildid, build target, and channel would fit, at the very least.

Nick and I talked a lot about this yesterday. We went back and forth on whether or not the approach in comment #4 is better than a one-table-per-url-version approach. The main benefit to the approach in comment #4 is having rules that can apply to multiple schema versions. However, the only use case we could think of for that is for version 2 URLs using the same rules as version 3. Given that that's a deprecated version, and a subset of the parts of version 3, we decided that we could satisfy that without doing full support for additional schemas like this bug is talking about. version 4 (the only other version still in use) can also be implemented similarly. So, we're punting on this bug for the purpose of nightly updates in production. Support for 2 & 4 is now in bug 879813.

mass component change

Support for /update/2 and /update/4 was added in bug 879813. /update/1 was added in bug 1026827. We didn't end up needing any rules table restructuring, we just ignore fields like distribution for update URL versions that don't support them.