1588113 - Only disallow downgrades to a lower major version of Firefox.

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P1)

Description

[Mike Kaply [:mkaply]]

Downgrade protection should only be based on major versions

Our latest breakage with our dot release is a great example of the problem.

Going from 69.0.2 to 69.0.1 caused a downgrade message and it should not have.

We don't (or at least we shouldn't) make profile changes in dot releases, so we shouldn't need to invoke downgrade protection in those cases.

Comment 1

[Dave Townsend [:mossop]]

This is a product call, but when we discussed this I know JoeH was against it.

Comment 2

[jhudson]

On the other hand, every few releases I have to downgrade a major version because of yet another accessibility bug. Profiles should be downgradable.

Comment 3

[Romain Testard [:RT]]

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

This is a product call, but when we discussed this I know JoeH was against it.

We have evidence from a large deployment that downgrade protection brings arguments to avoid deploying security patches in automated ways because of concerns that roll-backs won't be possible (i.e they will have to focus on testing more to ensure no regressions are introduced to green light dot release roll-outs).
I'll summarize the situation in a document that I'll get mossop and Mike to review prior to getting Joe's input.

Comment 4

[Dave Townsend [:mossop]]

Attachment: Bug 1588113: Only consider the major version part when checking for downgrades. r=glandium!

Comment 6

[[e-mail]]

Currently downgrade protection isn't even based on version comparison. Instead, it is based on compilation timestamp comparison, see bug 1629288

This issue should be fixed first.

Comment 7

[Dave Townsend [:mossop]]

(In reply to [e-mail] from comment #6)

Currently downgrade protection isn't even based on version comparison. Instead, it is based on compilation timestamp comparison, see bug 1629288

Downgrade protection does currently compare the version, it just falls back to build ID if the versions match, as they do in your example in that bug

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ffa15679931a
Only consider the major version part when checking for downgrades. r=glandium

Comment 9

[[e-mail]]

Please also don't fall back to build ID, as it is currently the case.

Comment 10

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/ffa15679931a

Comment 11

[Dave Townsend [:mossop]]

(In reply to [e-mail] from comment #9)

Please also don't fall back to build ID, as it is currently the case.

This change does that.

Comment 12

[Pintoch]

Thank you for fixing this important bug.
I believe this patch should be backported to all supported major releases - it should not be just in a new major release, for obvious reasons.

Comment 13

[Wayne Mery (:wsmwk)]

Good for lifting to 68 ESR?

Bug 1642263 is an example that needs this

Comment 14

[Matt]

I find this build checking onerous at best and madness at worst. Get a try build, use it with your existing daily profile. now you have to mess with command line option to continue to use that profile with daily. THen you make it look only to major builds. Does that mean I have to "force" the profile into the last major build and then mess with getting it into the daily build again?

I am confused and really this whole profile downgrade thing is a poor response to not offering downgrade of data/ backwards compatibility after a change. If you are redesigning a file or data, you are writing a converter, so you will have no issue at all marking the change as breaking existing data. Why an assumption that every change is breaking. Developers should be flagging the patch as breaking so the profile can be marked as compatible with a minimum version. Such change should also be a consideration for release on ESR channel given data format changes are hardly security and stability changes.

Comment 16

[Pintoch]

Just noting that this affects Thunderbird too - a backport to Thunderbird's maintained releases would be highly appreciated. Thank you very much for your work.

Comment 17

[Dave Townsend [:mossop]]

It's safe enough, but I think that product should make a call on whether that is a change appropriate in the middle of an ESR cycle.

Comment 18

[Romain Testard [:RT]]

Since disallowing downgrades was not a feature originally requested by enterprise users I don't feel there is a risk to bring this change to ESR 68.10 (i.e no expectation anyone would rely now on the new behavior) - very unlikely enterprises would be upset there, I assume most would be happier if the change comes-in earlier.
No product changes are made in-between main ESR releases although this can probably better considered as a bug fix - Mike do you see issues with lifting this to ESR?

Comment 19

[Mike Kaply [:mkaply]]

I see no issues with uplift.

Comment 20

[Romain Testard [:RT]]

Great, let's uplift to ESR68.