[Environmnets:] tested on OSX 10.13, Windows 8.1 most likely reproducible on all platforms and versions [Steps:] 1. Clean environment. 2. Install Nightly and Beta non-dedicated versions. 3. Start both of the above versions. (Beta first, Nightly second) 4. Replace content for Nightly with Nightly Dedicated profile. (simulates update) 5. Start Nightly Dedicated. 6. Replace content for Beta with Beta Dedicated profile. (simulates update) 7. Start Beta Dedicated profile. [Actual Result:] 3. Both versions start and use 'default' profile. 4. 'default' profile is taken over by becoming a dedicated profile. 7. Since 'default' profile is already a dedicated profile, a new dedicated profile is created for 'beta' [Expected Result:] From technical point of view, the above is correct: I. empty stub 'default' profile for old versions II. taken-over 'default' dedicated profile III. new 'default' dedicated profile for 2nd dedicated installation The problems that will start to arise when we move throught the channels as follows: T0. dedicated lands in Nightly. a. single installtion users (Nightly or otherwise) are not affected negatively by the change. b. multiple installation users (Nightly + something else) are affected by getting a blank profile on the non-nightly installation after Nightly with dedicated run. T1. dedicated moves to Beta a. single installtion users (Beta or otherwise) are not affected negatively by the change. b. multiple installation users (Beta + Nightly/Release/ESR) are getting blank profiles on the non-dedicated versions after running Nightly/Beta dedicated first - *over simplifying a bit the scenarios here (bug 1491404 will be probably hit - and also depends if the user has already a dedicated installation) T2. dedicated moves to Release a. single installtion users (Release or otherwise) are not affected negatively by the change. B. multiple installation users (Release + ESR) will getting blank profiles on non-dedicated installations (ESR) - *over simplifying a bit the scenarios here (bug 1491404 will be probably hit - and also depends if the user has already a dedicated installation) T3. dedicated moves to ESR a. single installation users (ESR or otherwise) are not affected negatively by the change. b. multiple installations users (ESR + any other version) will have already hit the 1491404 by this point, and it's quite possible that by this point a blank dedicated profile is created for most ESR users, since the data default user profile is already a dedicated profile for a dedicated version. [Note:] As discussing with Dave the other day, there are two code paths for an *initial* update and profile take over: case1: open version, update version to dedicated (default profile is taken over) case2: open version, open other_version, update version to dedicated profiles (brand new dedicated profile is created) The main update scenario for multiple installs will be case1, mostly certain that with the current update mechanism, we will be rarely hit case2, hence we are not covering case2 in the above discussion.

Since it wasn't my intention to fill in another fluffy issue, let me simplify: For single installation user, nothing changes. For a dual installation user, Nightly and Release for example, when users updates Nightly to Nightly dedicated profiles, they will have all user data in Nighly_Dedicated, and a blank user data in Release. For multiple installation user, the lowest importance versions will get the user data profile, depeding on the order in which they are run; for each new dedicated profiles installation, they will hit bug 1491404. For profile manager + multiple installation users, the default data profile will be stuck on the lowest importance version, and using profile manager will hit downgrade scenario block. "lowest importance version" - although improper, means that Release or ESR is considered more relevant to an user than Nightly.

I'm not really sure I see the issue here. It is intentional that the other, older builds get a different profile for use, which will eventually be converted to a dedicated profile as they upgrade their other installations. It's not ideal that we have this slow transition as the different channels update to dedicated profiles over time but I don't see a better way to handle this.

I think that the real problem here is that we just don't know how many users we will impact when landing and how many users we are impacting when moving through the trains with it. My suggestion would be to move this bug to confidential and ask Romain to redo the DAU count which switch installations. In the initial count of how many users would be impacted, the count was using these pre-requisites:

- 0.5 sample DAU during 1 week - switch from 1 channel to other at least twice in 60 days I think that we would need to look at: - users that switched channels at least once - time frame of one iteration (I would guess for example that users would switch to nightly/beta more before and after the version change milestones) - it would probably help to find out how many DAU are one-time switchers and how many DAU are reccurent switchers