Bugzilla

(In reply to Florian Quèze [:florian] from comment #17)

> (In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #15)
> 
> > > How would the beta->rc->beta case work in that case? I assume the rc would still 'just' have "release", not "release-beta" baked in... right? How would the update server know to serve beta updates to people on the rc build (having "come there" from beta)?
> > 
> > Beta would have an external file that the contents of is appended to the base channel. So, an RC and a Beta build would both have a base channel name of "release" and Beta would have this external file that contains "beta" which would make the channel "release-beta". The external file typically wouldn't be updated (deleted or modified) similar to how the channel-pref.js file isn't updated.
> > 
> > This wouldn't get rid of the IO on Beta and Aurora of course. The reason I originally considered going down this path is that there are clients that have a modified channel name and this would allow us to continue to update them.
> 
> Would it be possible to have non-release builds (beta/aurora/nightly) save their update channel into a user pref (so saved in the user profile, rather than in the application folder), and to have all builds (including release, RC) read that pref. If the pref exists and its value is different from the current build's built-in channel, we would send <built-in channel>-<channel name from the pref> as the update channel.
> 
> Ie. RC builds would send "release-beta", beta builds would send "beta".
> 
> This doesn't require any extra file, so no additional I/O.
> 
> I think this would have been a problem if a user had the same profile for multiple builds, but now that we are switching to a profile-per channel model, it might be ok.

Possibly though it would break updates and thereby orphan the client for the aurora and nightly channels if the client changed the value since there is a security team channel requirement that has an exception for beta and release. If this were the case we wouldn't actually need the base channel name either though it would likely be something 3rd parties that compile Firefox with update enabled would want.

Also, comment #19

To avoid this I'd much prefer just going with a separate file in the app dir that isn't read on startup except by app update when there is an update in progress and even that could likely be read at a later point.

What about having two omni.ja's for RC builds... one for beta and one for release? The two OS X bundles would have to be signed and MAR files for all platforms would have to be created for both the beta RC and release RC. This should be possible to automate without risking orphaning clients.

(In reply to Florian Quèze [:florian] from comment #17)

> (In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #15)
> 
> > > How would the beta->rc->beta case work in that case? I assume the rc would still 'just' have "release", not "release-beta" baked in... right? How would the update server know to serve beta updates to people on the rc build (having "come there" from beta)?
> > 
> > Beta would have an external file that the contents of is appended to the base channel. So, an RC and a Beta build would both have a base channel name of "release" and Beta would have this external file that contains "beta" which would make the channel "release-beta". The external file typically wouldn't be updated (deleted or modified) similar to how the channel-pref.js file isn't updated.
> > 
> > This wouldn't get rid of the IO on Beta and Aurora of course. The reason I originally considered going down this path is that there are clients that have a modified channel name and this would allow us to continue to update them.
> 
> Would it be possible to have non-release builds (beta/aurora/nightly) save their update channel into a user pref (so saved in the user profile, rather than in the application folder), and to have all builds (including release, RC) read that pref. If the pref exists and its value is different from the current build's built-in channel, we would send <built-in channel>-<channel name from the pref> as the update channel.
> 
> Ie. RC builds would send "release-beta", beta builds would send "beta".
> 
> This doesn't require any extra file, so no additional I/O.
> 
> I think this would have been a problem if a user had the same profile for multiple builds, but now that we are switching to a profile-per channel model, it might be ok.

Possibly though it would break updates and thereby orphan the client for the aurora and nightly channels if the client changed the value since there is a security team channel requirement (there is an exception for beta and release). If this were the case we wouldn't actually need the base channel name either though it would likely be something 3rd parties that compile Firefox with update enabled would want.

Also, comment #19

To avoid this I'd much prefer just going with a separate file in the app dir that isn't read on startup except by app update when there is an update in progress and even that could likely be read at a later point.

What about having two omni.ja's for RC builds... one for beta and one for release? The two OS X bundles would have to be signed and MAR files for all platforms would have to be created for both the beta RC and release RC. This should be possible to automate without risking orphaning clients.