nthomas, for my own understanding, the additional files would be the same as if there was an additional beta build though the only file that would need to be updated is in the omni.ja? (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? > > 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? At a minimum to lessen update watersheds the following would need to be done: 1. balrog would need to not update beta clients that haven't updated to a build with the change to an RC since this file is what prevents them from moving to release. 2. the mar generation scripts would need to add the new file with the add-if-not instruction which adds the file if it doesn't exist. This is already done for the channel-prefs.js file and should be somewhat trivial. Without the balrog changes for beta in "1." above there would have to be an update watershed to update to the build previous to an RC.
Bug 1541601 Comment 31 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
nthomas, for my own understanding, the additional files would be the same as if there was an additional beta build though the only file that would need to be updated is in the omni.ja so there would be one for beta and one for release? (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? > > 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? At a minimum to lessen update watersheds the following would need to be done: 1. balrog would need to not update beta clients that haven't updated to a build with the change to an RC since this file is what prevents them from moving to release. 2. the mar generation scripts would need to add the new file with the add-if-not instruction which adds the file if it doesn't exist. This is already done for the channel-prefs.js file and should be somewhat trivial. Without the balrog changes for beta in "1." above there would have to be an update watershed to update to the build previous to an RC.
nthomas, for my own understanding, the additional files would be the same as if there was an additional beta build though the only file that would need to be updated is in the omni.ja so there would be one for beta and one for release? (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? > > 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? At a minimum to lessen update watersheds the following would need to be done: 1. balrog would need to not update beta clients that haven't updated to a build with the change to an RC since this file is what prevents them from moving to release. 2. the mar generation scripts would need to add the new file with the add-if-not instruction which adds the file if it doesn't exist. This is already done for the channel-prefs.js file and should be somewhat trivial. Without the balrog changes for beta in "1." above there would have to be an update watershed on beta to update to the build previous to an RC.
nthomas, for my own understanding, the additional files would be the same as if there was an additional beta build though the only file that would need to be updated is in the omni.ja so there would be one for beta and one for release? (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? > > 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? At a minimum to lessen update watersheds the following would need to be done: 1. balrog would need to not update beta clients that haven't updated to a build with the change to an RC since this file is what prevents them from moving to release. 2. the mar generation scripts would need to add the new file with the add-if-not instruction which adds the file if it doesn't exist. This is already done for the channel-prefs.js file and should be somewhat trivial. Without the balrog changes for beta in "1." above there would have to be an update watershed on beta to update to the build previous to an RC. Edited to add that if we go with this change that at some point we'll want balrog to advertise updates clients that have a suffix other than beta or aurora to release with a complete update so those clients aren't orphaned.
nthomas, for my own understanding, the additional files would be the same as if there was an additional beta build though the only file that would need to be updated is in the omni.ja so there would be one for beta and one for release? (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? > > 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? At a minimum to lessen update watersheds the following would need to be done: 1. balrog would need to not update beta clients that haven't updated to a build with the change to an RC since this file is what prevents them from moving to release. 2. the mar generation scripts would need to add the new file with the add-if-not instruction which adds the file if it doesn't exist. This is already done for the channel-prefs.js file and should be somewhat trivial. Without the balrog changes for beta in "1." above there would have to be an update watershed on beta to update to the build previous to an RC. Edited to add that if we go with this change that at some point we'll want balrog to advertise updates clients that have a suffix other than beta or aurora (we might not need to do this for aurora) to release with a complete update so those clients aren't orphaned.