1995391 - newtabTrainhopAddon should allow co-enrollment, prioritizing the enrollment with the highest version number

Status: RESOLVED FIXED

(Firefox :: New Tab Page, task)

Description

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

We recently did our second production train-hop for newtab, while a pre-existing train-hop existed that had originally targeted Firefox 143.

The original train-hop (145.0.20250919.173227) was rolled out with this experiment, which had a min version of 143.0 and a max version of 145.0. That max version meant that were we to not do any additional train-hops, then as the major version number passed 145, clients would naturally un-enroll and the train-hop would start to "fade away" for clients that had upgrade.

We decided, however, to train-hop during the Firefox 144 release cycle (145.1.20251009.134757). That put us in an awkward spot, since the original experiment could not be updated to change its max / min version, and we wanted to roll out the new train-hop at 25% without downgrading any clients that had received the prior train-hop. What we ended up doing was creating and deploying 3 new rollouts, in this precise order:

1. An experiment to target just Firefox 143 on the release channel, and to continue having it ship the original 145.0.20250919.173227 train-hop at 100%.
2. An experiment to target Firefox 144 to Firefox 145 on the release channel, and to continue having it ship the original 145.0.20250919.173227 train-hop at 75%.
3. An experiment to target Firefox 144 to Firefox 145 on the release channel, and to have it ship the new 145.1.20251009.134757 train-hop at 100%.

Then we ended the original experiment.

Today, once we were ready to go to 100% deployment, we ended the second experiment that was as 75%, thus deploying 145.1.20251009.134757 to 100% of the release audience.

This was pretty annoying and cumbersome. Having spoken to Beth about this a few weeks back, here's what I propose:

1. Have the newtabTrainhopAddon feature become a co-enrollment feature
2. Have clients examining that feature prioritize the enrollment with the highest version number.

That way, in theory, we can have clients enrolled in multiple overlapping rollouts touching newtabTrainhopAddon, but the highest version number will win. That means that in the future, instead of doing the same steps as above, we'd:

1. Create an experiment that targets 25% of the release population with the new train-hop
2. Deploy it, ensuring that the version number being supplied is greater

This does mean that we're likely going to have this long tail of running rollouts as major version numbers increase, and the support window for each train-hopped XPI changes. We'll probably want to only end these rollouts once the daily population falls below some threshold.

Comment 1

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

Attachment: Bug 1995391 - Use co-enrollment for newtabTrainhopAddon Nimbus feature to make newtab trainhop rollouts less cumbersome. r?#home-newtab-reviewers!,rpl!

Comment 2

[Jack Brown]

Attachment: Bug 1995391 - Add newtabTrainhopAddonDeployment co-enrollment feature, prioritize highest version - r=mconley,rpl

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6c2bf8c9d302
https://hg.mozilla.org/integration/autoland/rev/5ac4db2dbec0
Add newtabTrainhopAddonDeployment co-enrollment feature, prioritize highest version - r=mconley,rpl

Comment 4

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/5ac4db2dbec0