Set Firefox Version in rapid recipe

[jaredlockhart]

We have a Firefox Version field in the rapid UI, but it's not connected to the backend yet. It's not clear to me how that field relates to our existing concepts of 'firefox min version' and 'firefox max version' that we use to create the recipe. Also how will the choice of firefox version be reflected in the recipe? How does it get into the filter expression?

Marking this as blocked pending feedback from @k88hudson and @AnaMedinac and @tdsmith

[pdehaan]

Which API are you referring to? Will this be something in Experimenter, something via nimbus-shared module, or is there a Firefox/Bugzilla API for version numbers?

[pdehaan]

Per mozilla/nimbus-shared#59, do we still need the Firefox Version dropdown field in the UI, or are we hardcoding everything for Release channel only?

[k88hudson]

For MVP i think we could get away with having this be not in the UI and targeting the current version only – however, in the future I would imagine the default for this being the current release version, with the ability to edit it. What do you think @AnaMedinac @tdsmith, does that fit with most existing use cases?

[tdsmith]

I think it makes the most sense to allow users to specify a minimum version; I think we will often want to synchronize message launches with feature availability. Deploying a message to the release channel is not sufficient to restrict it to users that have the ability to use a feature.

Experiment owners usually don't want a maximum version constraint; AIUI that's imposed to limit release QA work.

[pdehaan]

allow users to specify a minimum version

@tdsmith What is a "minimum version"? Are you thinking major releases (78.0, 79.0, etc) or more like minor/patch versions (78.0.2, 79.1)

[tdsmith]

We've expressed constraints on build_id before 🙃 but I think major version should be sufficient for most use cases