If all Firefox versions from 4.0 onwards are going to point at the latest beta/release build I'd like to avoid writing a separate set of rules for 4.0*, 5.0*, 6.0* and so on. This may mean we want to say version > '4.0' instead of a wildcard match.
This might be as easy as making high priority rules which match on specific old versions, and lower priority rules matching on version=* for rapid releases. eg: in (priority, mapping, version) style, thinking about just release channels (100, 'Firefox-3.6.19-build1', '3.6*') (100, 'Firefox-3.6.18-build1', '3.5*') ... over old releases ( 50, 'Firefox-5.0.1-build1', '*') We still need to flesh out our story for managing rules and what to do if multiple rules match (most-matching applies?).
mass component change
The way we release has changed a bunch since this was file. Comment #1 seems reasonable, unless we find that we end up with a lot of rules. Different matching schemes might help in that case.
Does the version comparison stuff that's been done cover everything here? We're certainly not in a situation where we usually need more than 1 rule per channel (ignoring os blocking).
Should be OK with what we have.