505167 - maxversion x.y should be interpreted as x.y.* not x.y.0

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Daniel Veditz [:dveditz]]

Every time we release a new major version we have to work hard to get addons upgraded to be compatible, and then inevitably we release the .1 version and break some number of them. Then we get user complaints like bug 505159 (.net and norton 360 broken) and bug 495628. The current treatment of maxversions like X.Y goes against the grain of author expectation and doesn't match the most commonly used and intended value.

I propose that the addon manager compatibility algorithm treat maxVersions with one or two dots as if there were an implied ".*" on it. maxversions with no dots would be treated as x.0.* and three dots would be left alone because we only support four-place versions

minversion would not be treated any differently, they would continue to be interpreted as if padded with .0.0

Should an addon really need to be compatible with the initial 3.5 and no other they would have to explicitly state maxVersion 3.5.0 or 3.5.0.0 -- it is right to make them take the extra step to be careful because that is not the common case.

maxVersion            interpreted as
----------            ---------------
X                     X.0.*
X.Y                   X.Y.*
X.Y.Z                 X.Y.Z.*
W.X.Y.Z               W.X.Y.Z

Comment 1

[Daniel Veditz [:dveditz]]

I realize the no-dot variant is logically inconsistent but it does match our shipping practice.

Also note that this problem cannot be solved by AMO alone through review-guidelines or automatic checking because addons not served from AMO have the same problem, and in fact have it worse because they often have no good update mechanism.

Comment 2

[Benjamin Smedberg]

I realize you want to improve extension compatibility, but I think the current system is already confusing enough for authors and the EM and adding magic version rewriting would only confuse matters further. Recommend WONTFIX pending thoughts from Mossop.

Comment 3

[Daniel Veditz [:dveditz]]

Exactly, the current situation is confusing. When an addon author says their addon is compatible with "3.5" they think they mean "all of 3.5". Who seriously is saying "I'm so afraid you'll break me I really mean 3.5.0.0". I think _that_ is the magic version rewriting, everyone else (we haven't trained) is thinking it matches the parts that show.

I withdraw my no-dot proposal (X -> X.0.*) as inconsistent so don't let that be a stumbling block. I'm primarily concerned with X.Y versions anyway. When .NET or Norton, or some other non-AMO addon has the wrong version in it the compatibility warning discourages some number of users from upgrading to get important security fixes. Even if the user didn't know they had the whatever and didn't ask for it, they don't necessarily understand. All they see is that we're warning them that something is going to break, and things are working OK right now so better to not mess with it by upgrading.

Comment 4

[Justin Scott [:fligtar]]

I think this is a good idea.

Comment 5

[Samuel Sidler (old account; do not CC)]

I don't think Dan meant to mark this as needed for 1.9.1.

Comment 6

[Daniel Veditz [:dveditz]]

If we can't get client-side support for this, could the AMO auto-scan reject versions without at least two dots and/or a wildcard?
  x     -> AMO rejects (must be explicitly x.0.0)
  x.y   -> AMO rejects (must be explicitly x.y.0)
  x.*   -> OK? perhaps unwise but at least it's clear what they mean.
  x.y.z -> OK
  x.y.* -> OK

Comment 7

[Dave Townsend [:mossop]]

AMO uses a whitelist of allowable maxVersions, the current list is visible at https://addons.mozilla.org/en-US/firefox/pages/appversions. I don't think about of them are problematic.

Comment 8

[Benjamin Smedberg]

I think what the security guys want to prevent is maxVersion=3.5

I think we could solve that by simply only including maxVersion=3.6.0 in the whitelist, so if you use 3.6 in either the minVersion or maxVersion field it will reject the addon.

Comment 9

[Dave Townsend [:mossop]]

Good point. I think an AMO bug would need to be filed to allow for a separate whitelist for the minVersion and maxVersions

Comment 10

[Benjamin Smedberg]

Sure, but is that necessary? Could we just say you have to use minVersion=3.6.0 if in fact that's the minversion for your extension? That doesn't seem like a big deal to me.

Comment 11

[Daniel Veditz [:dveditz]]

I'd really rather have the client fix requested in this bug. The biggest problems have come from common addons not hosted on AMO where the manual review process (and cultural knowledge?) usually weeds out this problem.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, but if we can figure out a plan that works, we'd take a fix

Comment 13

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.