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?).
Summary: Need to write concise rules for rapid releases → Need to write concise rules in AUS3 for rapid releases
Component: Release Engineering → Release Engineering: Automation
Priority: P3 → --
QA Contact: release → catlee
Priority: -- → P3
Whiteboard: [updates] → [updates][balrog]
Product: mozilla.org → Release Engineering
mass component change
Component: General Automation → Balrog: Backend
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.
Whiteboard: [updates][balrog] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2810] [updates][balrog]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2810] [updates][balrog] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2818] [updates][balrog]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2818] [updates][balrog] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2820] [updates][balrog]
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.