601836 - Remote compatibility updates do not work for old addon versions (old AMO buttons don't work as indicated)

Status: RESOLVED DUPLICATE of bug 610041

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

Description

[Dave Garrett]

STR:
0) new profile in latest Minefield
1) https://addons.mozilla.org/en-US/firefox/addon/4664/versions/
2) Click to install version 2.9.9 -> prompts to install (just cancel it)
3) Click to install version 2.9.8 -> says it's not compatible and can't install

Both versions list compatibility with Firefox Firefox 3.5 - 4.0b8pre, however the newer one does so via the install.rdf whilst the older does so via a remote compatibility bump. It seems this isn't being checked here.

Not sure if this is a client or server side bug.

Tested on Linux and WinXP.

Comment 2

[Dave Garrett]

Not a dupe of bug 476232. This is not about update checking; this is about clicking the install button for separate versions on the all versions page.

Comment 3

[Dave Garrett]

Just tried installing Flagfox 3.3.17 (which is remote bumped to support Firefox 3.6.*) under Firefox 3.6.10 and got to the install prompt, but it gave an incompatible error on attempt, so this isn't a regression. Probably another bug somewhere to dupe to, then.

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #3)
> Just tried installing Flagfox 3.3.17 (which is remote bumped to support Firefox
> 3.6.*) under Firefox 3.6.10 and got to the install prompt, but it gave an
> incompatible error on attempt, so this isn't a regression. Probably another bug
> somewhere to dupe to, then.

Compatibility bumps are achieved through the update service. Because AMO only includes information about the newest version of an add-on in the update.rdf data returned compatibility bumps have no effect for older versions of add-ons and so Firefox will see them as incompatible.

Comment 5

[Dave Garrett]

Makes sense, but that means that the cause is duplicated but this bug is different still. In other words, clicking an install button shouldn't be using the update service like this. It should be checking separately. This means that there's many buttons lying on AMO as to whether they can install or not.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> Makes sense, but that means that the cause is duplicated but this bug is
> different still. In other words, clicking an install button shouldn't be using
> the update service like this. It should be checking separately. This means that
> there's many buttons lying on AMO as to whether they can install or not.

If you like.

Comment 7

[Dave Garrett]

Ok, then the simplest route would be to not show the old remote compatibility bumps on the all versions pages. In fact, if bug 476232 or something else new is required for this to work as it should, then compatibility bumps should only be doable at all for the latest version in the channel.

This would mean:
a) No editable version fields in the developer control panel for old versions
b) Pushing a new version public wipes past version bumps
c) Adding a new beta version wipes past beta version bumps
d) All non-latest-versions of all addons need their compatibility bumps wiped

This is however a bit annoying, as it resets various legitimately set version bumps. Would be better than broken buttons, though.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

A bug like that one blocks us from doing efficient testing with older versions of add-ons. Also users can be irritated when they want to install an add-on from AMO via the green button, but the installation fails. We clearly show the compatibility info on AMO, so the installation should pass when the application version is in that range.

Comment 11

[Dave Garrett]

I'd rather the buttons work as directed too. Dave Townsend was the one who decided that he'd rather they just not lie instead of make them work. Apparently truly fixing this would take some work (this is not a regression; comment 3).

Comment 12

[Dave Garrett]

Changing bug title to be easier to find and neutral. Either needs a fix to have the buttons work always or a fix to make them say what they'll really do.

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #11)
> I'd rather the buttons work as directed too. Dave Townsend was the one who
> decided that he'd rather they just not lie instead of make them work.
> Apparently truly fixing this would take some work (this is not a regression;
> comment 3).

It isn't really my call how AMO works, I only know that if we want this to work AMO have to fix it and they have indicated in the past that they do not want to (see bug 476232).

There is nothing new here, this should not block the Firefox release.

Comment 14

[Justin Scott [:fligtar]]

This is something that will be fixed when we port the update servie to zamboni.

Comment 15

[Dave Garrett]

(In reply to comment #14)
> This is something that will be fixed when we port the update servie to zamboni.

How fixed? Are we going to get bug 476232 fully fixed and allow updating to latest compatible version? (I hope)

Comment 16

[Justin Scott [:fligtar]]

We can sort versions via SQL queries properly now, so it should be entirely fixed.