Bugzilla

(In reply to :Gijs (he/him) from comment #30)

> I'm a little bit puzzled. What does 'watershed' mean in this context? I'm assuming the updater could rm the old channel-prefs.js file and create the new file with the "right" contents... is that a mistaken assumption?

A watershed is update jargon for a version which users must update to before continuing, eg old -> intermediate -> latest. We've used these to change the compression algorithms and crypto used in the update file packaging, where the intermediate build supports the new functionality.

 > That is, from the app's perspective, all that needs to happen is updating a bunch of references and creating a '.dat' or '.ini' or whatever file that only contains the channel, nothing else, and lives outside the defaults/pref/ directory. I assumed that the updater could take care of migrating the channel-prefs file to the new file, and ensuring the old file is removed and the new file has the "right" content. I assume it needs to be done by the updater because it will need elevated privileges on some systems. Is there something I'm missing in that respect?

The updates currently include channel-prefs.js with an `add-if-not` instruction - the idea is to leave the file alone unless it has somehow disappeared. This prevents an RC update moving a beta user to release, which a simple `add` instruction would do by overwriting the file. 

The updater doesn't support a move instruction ([here's what it does support](https://hg.mozilla.org/mozilla-central/file/7c41e561912d/toolkit/mozapps/update/updater/updater.cpp#l16)) so we have to create the new file. I think Rob and I are suggesting we just move the existing `add-if-not` handling to the new file. Doing that, the baked in channel will be wrong for the RC build, so beta users would need a watershed where the intermediate is a genuine beta build.

(In reply to :Gijs (he/him) from comment #30)

> I'm a little bit puzzled. What does 'watershed' mean in this context? I'm assuming the updater could rm the old channel-prefs.js file and create the new file with the "right" contents... is that a mistaken assumption?

A watershed is update jargon for a version which users must update to before continuing, eg old -> intermediate -> latest. We've used these to change the compression algorithms and crypto used in the update file packaging, where the intermediate build supports the new functionality.

 > That is, from the app's perspective, all that needs to happen is updating a bunch of references and creating a '.dat' or '.ini' or whatever file that only contains the channel, nothing else, and lives outside the defaults/pref/ directory. I assumed that the updater could take care of migrating the channel-prefs file to the new file, and ensuring the old file is removed and the new file has the "right" content. I assume it needs to be done by the updater because it will need elevated privileges on some systems. Is there something I'm missing in that respect?

The updates currently include channel-prefs.js with an `add-if-not` instruction - the idea is to leave the file alone unless it has somehow disappeared. This prevents an RC update moving a beta user to release, which a simple `add` instruction would do by overwriting the file. 

The updater doesn't support a move instruction ([here's what it does support](https://hg.mozilla.org/mozilla-central/file/7c41e561912d/toolkit/mozapps/update/updater/updater.cpp#l16)) so we have to create the new file. I think Rob and I are suggesting we just move the existing `add-if-not` handling to the new file. Doing that, the baked in channel will be wrong for an update to the RC build, so beta users would need a watershed where the intermediate is a genuine beta build.