Do not auto-increment maxVersion for addons with strictCompatibility="true"

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
5 years ago
3 years ago

People

(Reporter: haqer, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

1. Set strictCompatibility="true"
for an addon meant to be compatible with Firefox x (maxVersion="x").
2. Uploaded that version and had it reviewed.

P.S. E.g., https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/


Actual results:

3. AMO changed addon to maxVersion="{x+1}"
4. User upgrades Firefox to x+1.
5. Firefox doesn't check for availability of new updates during upgrade (apparently due to 3.). 
6. User's mozilla app profile is broken, or the addon isn't working even though there are no visible signs of an issue.


Expected results:

AMO shouldn't change addon maxVersion when strictCompatibility="true": this should lead to the addon getting disabled or updated during app upgrade (5. above), and prevent the issue in 6. above.
(Reporter)

Comment 1

5 years ago
Additional info: even if the addon developer changes maxVersion back to x as step 3.1., the issue still happens: apparently, the app caches maxVersion of x+1 looked up after step 3., and it either doesn't change back to x after step 3.1 at all, or only changes if the user profile is running a certain amount of time (e.g., a day or a few days) between steps 3.1 and 4.
(Reporter)

Comment 2

5 years ago
Bug 857431 provides some more details for some occurrences of the issue discussed here.
We include add-ons with strictCompatibility intentionally. We also message all developers who have their add-ons automatically upgraded so that they have the opportunity to roll back the version bump. That's easy enough to do in the Status & Versions page.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

5 years ago
(In reply to Jorge Villalobos [:jorgev] from comment #3)
> We include add-ons with strictCompatibility intentionally. We also message
> all developers who have their add-ons automatically upgraded so that they
> have the opportunity to roll back the version bump. That's easy enough to do
> in the Status & Versions page.
It's easy to do, but:
1. The issue happens even after manually going to Status & Versions, and changing maxVersion back to a proper value.
2. The issue maybe more likely to happen if the 1st step is not made as soon as possible after AMO's auto-increment: so if one doesn't have time to check the email account, see the email, login to AMO, and change the version, the issue is apparently more likely to happen the more days auto-incremented version is out there (because the app apparently caches maxVersion that it gets).
3. The manual step appears redundant: strictCompatibility (to me anyway) implies not messing with maxVersion automatically.

P.S. If strictCompatibility isn't going to be used to tell AMO not to auto-increment maxVersion, what other way is there?
a. Can one ask for a specific addon of his/her not to be auto-incremented?
b. Perhaps we need an AMO (DB) setting that developers can use to request this for specific addons?
You only need to revert the compatibility bump once. If your latest add-on version is compatible with 21, we will try to upgrade to 22. If you revert that change, that version will not be considered for a compatibility bump again.

Your case is very unusual because it's an add-on that shouldn't be an extension, and you need a new version for each Firefox release, and it need to have strictCompatibility. I'm sorry, but I don't think we should change anything on our side to accommodate these unusual circumstances.
(Reporter)

Comment 6

5 years ago
(In reply to Jorge Villalobos [:jorgev] from comment #5)
> You only need to revert the compatibility bump once. If your latest add-on
> version is compatible with 21, we will try to upgrade to 22. If you revert
> that change, that version will not be considered for a compatibility bump
> again.
That doesn't really help: there's a race condition (between your bump and my revert, the app caches your bump in some user profiles, which causes issues (broken profiles) upon app upgrade); and this will repeat every 6 weeks indefinitely.

(In reply to Reşat SABIQ (Reshat) from comment #4)
> P.S. If strictCompatibility isn't going to be used to tell AMO not to
> auto-increment maxVersion, what other way is there?
> a. Can one ask for a specific addon of his/her not to be auto-incremented?
I'm concluding that the answer is "no".
> b. Perhaps we need an AMO (DB) setting that developers can use to request
> this for specific addons?
I'll consider logging a bug for this...

The only other option to resolve this appears to be fixing the testing done to determine whether to do auto-incrementing: well, that's a heck of thing for me to fall into because i've never even seen that code, and don't know where to start, but i'll consider looking into it when and if i have time.
(Assignee)

Updated

3 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.