360582 - [VersionCheck.php] AMO chokes on versions with multiple modifiers, i.e. "2.0b1pre"

Status: RESOLVED WORKSFORME

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[J. Paul Reed [:preed]]

Thunderbird on the 1.8 branch currently has a version of 2.0b1pre, signifying that the current nightlies are pre-b1 builds.

AMO reportedly chokes on this version.

Not entirely sure what the solution should be; it might make sense, for the purpose of version checks, to chop the "pre" off.

I'd take a look at the code, but I'm also not sure whether this is server side or client side.

Comment 1

[Benjamin Smedberg]

There are several AMO bugs about dealing with version numbers properly. Not sure what the status is with those.

Comment 2

[Justin Scott [:fligtar]]

https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id={B17C1C5A-04B1-11DB-9804-B622A1EF5492}&version=1.0.6&maxAppVersion=3.0a1&status=userEnabled&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}&appVersion=2.0b1pre&appOS=Linux&appABI=x86-gcc3

I haven't downloaded the Thunderbird version in question to test this, but the above update check works fine for me. Maybe client side?

The update check code is: http://lxr.mozilla.org/mozilla/source/webtools/addons/public/htdocs/update.php

Comment 3

[Justin Scott [:fligtar]]

(In reply to comment #1)
> There are several AMO bugs about dealing with version numbers properly. Not
> sure what the status is with those.

Because of all the bugs with it, we ended up taking the version check out of the code and now it just returns the latest version compatible with the application passed. So the version passed is irrelevant, it doesn't even use it now. So yeah, this bug is most likely client side.

Comment 4

[Mike Shaver (:shaver emeritus)]

What is the manifestation of "choke"?  Can you give us steps to demonstrate the problem, and say what alternate behaviour you would expect instead (if not blindingly obvious).

Comment 5

[Robert Kaiser]

What I heard is that on a Thunderbird nightly marked "2.0b1pre" the German dictionary from the dictionaries section at AMO does not install, though it's marked to be compatible 2.0a1-3.0a1 at AMO via the devcp.
Note that the install.rdf reports a maxVersion of 2.0a1, but AFAIK, TB should ask AMO for new info and then recieve the data from the devcp and should be OK.

Comment 6

[Mike Shaver (:shaver emeritus)]

Can someone who has experienced the problem tell how exactly to reproduce it, or better show the URL that was fetched from AMO and the content that came back?

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Should be marked as invalid because of http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Firefox_Versioning

Comment 8

[Mike Shaver (:shaver emeritus)]

No, as that section says, the version format was changed in Firefox 1.5 and subsequent releases to be the one described at http://developer.mozilla.org/en/docs/Toolkit_version_format .

"0b1pre" is a legal version-part according to that document, I very much believe.

Comment 9

[Justin Scott [:fligtar]]

Marking WORKSFORME as no new information has been received and I'm pretty sure this isn't an AMO-side problem - as I said above, the update checks don't even take into account the application's version anymore, they simply return the latest extension version compatible with the application. So, if TB does check AMO for the latest update, it is getting whatever was set in the dev cp for the latest version and it's Thunderbird that's not installing it properly.

If there is a first-hand account with STR that's getting bad info back from the update check, please re-open (or move to a different product).