Please comment in the Talk page (use the Discussion tab above)

Goals & Objectives

Primary:

• Increase participation in the application beta programs
  • This will improve the QA of our applications and the feedback on new features. If desired, applications can also advertise other repositories to update to by working with releng.
• Opt-in by the application
  • Some applications might not want to provide this ability to users so this functionality must be opt-in with the caveat that a user can currently accomplish the same affect by modifying files manually and this project will not prevent the user from doing this with the new or old files for configuring the update channel.

Secondary (non-goals but would be nice to have):

• Profile backup / restore
  • See Versioned Profile Backups

Planned Milestones

Overview

Background

This wiki page will serve as a planning page for providing the ability to change the Application Update channel. This work has not been prioritized with other work for the next delivery cycle and hence the delivery cycle for this feature has not yet been decided.

To increase the participation in and awareness of the Firefox beta program it would be fantastico to be able to provide the ability to change the update channel within the application.

Basic Methodology

To be able to set a different update channel we could use a file stored in a well known global location. For example, on Windows a file in a sub-directory of the "All Users" "Application Data" could be used to set the channel for the next update. The file would then be removed after the update to the new update channel has been successful since channel-prefs.js would then reflect the new update channel.

The channel would be configured via the Preferences / Options -> Advanced -> Update tab and possibly within the application update check ui as well.

The application would need to define the channels - if any - it wants to make available. It might also be a "good thing" for the application to not allow a release channel user to switch to the nightly channel as well as prevent changing to a lower release (e.g. beta to previous official).

Profile Backup / Restore (possible future)

Versioned Profile Backups

One suggestion for supporting downgrading in the future is versioned profile backups. Whenever the version of the application changes the application could create a backup of specific files within the user's profile necessary to restore the previous profile. The flow would be something along the lines of the following:

• On startup a component would compare the current version of the application with the last version of the application the profile was used with similar to how the extension manager does after an application upgrade. This would cover both application update upgrades / downgrades and when the user installed an upgrade / downgrade.
• The files specified by the application in the user's profile would be backed up. Issues with backing up the profile data and privacy would need to be addressed. A couple of possible user experiences for this are:
  • The user is asked if they would like to make a backup perhaps with a number of days to keep the backup.
  • The profile is backed up silently perhaps with a default number of days to keep the backup.

Note: the reasons to use a separate component instead of the updater or the Windows installer are as follows:

• it is not possible for either of them to access the profiles of other users on the system
• they both don't understand profiles and at the very least the Windows installer cannot share the application's profile code to be able to do so.
• these tasks can be much more simply accomplished as well as for all platforms by performing these tasks on startup after an application upgrade / downgrade in a similar manner as it is accomplished with the extension manager which is launched early during startup by nsAppRunner on application upgrade.

Weave Backup / Restore

faaborg suggested using Weave to accomplish this. Not sure how feasible this is or what it would take on the Weave side of things but it sounds good.

User Interface

TDB though there should be adequate warnings especially in regards to how this affects profiles.

Issues

• Any method we decide to use would allow users to "fight" (e.g. switching to and from) with the update channel.
• Switching to an update channel that is for a previous release (e.g. beta to previous official) could easily leave behind components from the newer version that would break the previous release. The current method used to mitigate this with the installer is to update removed-files.in for the current previous release with the files that need to be removed on downgrade. Perhaps there should be no option to go from a newer version to an older version?

Reference

Bugs:

410639 Provide ability to change update channel within the application