Better support for minVersion 4.0

VERIFIED FIXED in 6.0.0

Status

P2
normal
VERIFIED FIXED
8 years ago
3 years ago

People

(Reporter: fligtar, Assigned: andy+bugzilla)

Tracking

Dependency tree / graph

Details

(Reporter)

Description

8 years ago
Add-on detail pages have only ever been able to show the single latest version of an add-on. All smart-install checks and detection are done client-side because of caching, so we can't easily return the exact version compatible with a user's browser.

This becomes a huge problem every time we do a big release because of compatibility. Developers want to support the upcoming version of Firefox, but unless their package also works with the current version, uploading it means they will make it hard for the majority of users. We encourage developers to update compatibility for a new version of Firefox as soon as possible, even giving them prizes for doing so, but at the expense of all of the users on the stable version.

For Firefox 4, we'll see more add-ons than ever before uploading .xpis that only work with Firefox 4. As soon as they upload that minVersion of 4, the details page and update check will stop returning the 3.6 compatible version, screwing the vast majority of users.

We should make every effort to fix this before that starts happening, at least on the details page. This will probably involve sending 2 versions of an add-on to the install button and letting it choose the latest compatible one. The logic is probably something like:

if (latest_version's minVersion is >= 3.7)
  backup_version = most recent version with a minVersion < 3.7, if exists
else
  no backup version
(In reply to comment #0)
> For Firefox 4, we'll see more add-ons than ever before uploading .xpis that
> only work with Firefox 4. As soon as they upload that minVersion of 4, the
> details page and update check will stop returning the 3.6 compatible version,
> screwing the vast majority of users.

Is the update check something we be smarter about?  If we're presenting 3.6-compatible add-ons, there will probably be devs that want to fix bugs in their 3.6 version.
(Reporter)

Comment 2

8 years ago
Yes, when we port update checking to Zamboni I want to use the SQL version comparison stuff Dave implemented last year to actually return the latest compatible version. Right now it returns the latest version compatible with any version of the application.
Depends on: 611551

Updated

8 years ago
Duplicate of this bug: 615399
(Reporter)

Updated

8 years ago
Target Milestone: Q4 2010 → Q1 2011
-> andym since he's doing the blocking bug anyway.  Note that the update checking can't go live until bug 624095 is done, so CC yourself on that if you want to keep tabs on overall progress.
Assignee: nobody → amckay
Target Milestone: Q1 2011 → 5.12.12
(Assignee)

Comment 5

8 years ago
Update supports a minimum version, so that if you set the minimum version for an addon is 4.0, you won't get it. Adding tests for this now.
(Assignee)

Comment 6

8 years ago
jbalogh: anything we need to do for the install buttons?

https://github.com/jbalogh/zamboni/commit/c59405f99ae9829a3e144c3cb430d7a0b0add191
Assignee: amckay → jbalogh
1. Create Addon.backup_version that's like current_version but for 3.6.
2. Send two buttons down if there's a backup version.
3. Figure out which button we want to show.
(Assignee)

Updated

8 years ago
Assignee: jbalogh → amckay
Target Milestone: 5.12.12 → 6.0.0

Comment 8

8 years ago
Just curious if this is live - hard to tell from the latest comments.  Comment 4 suggests it depended on the now closed bug 624095 ?
If this isn't live yet, will it be before FF4 goes public?  Otherwise, I'll be waiting to post the FF4 version of my addon until the night before the Firefox release, which after waiting in the review queue, will unfortunately leave a window of time where users won't be able to update.
(In reply to comment #8)
> Just curious if this is live - hard to tell from the latest comments.  Comment
> 4 suggests it depended on the now closed bug 624095 ?
> If this isn't live yet, will it be before FF4 goes public?  Otherwise, I'll be
> waiting to post the FF4 version of my addon until the night before the Firefox
> release, which after waiting in the review queue, will unfortunately leave a
> window of time where users won't be able to update.

It is not live yet.  Depending on other bugs means those bugs need to be closed before this one can be.  It's scheduled to go live the Thursday after next.
(Assignee)

Comment 10

8 years ago
https://github.com/jbalogh/zamboni/commit/d6d56c0f635db5141f3c36ebade2c6ca51bdf4ea
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 11

8 years ago
Seeing that this bug was fixed I submitted the latest version of my addon (with minVersion 4.0) to the site but I'm disappointed to find out that the UI looks the same to users of Firefox 3.6.

Using Firefox 3.6, https://addons.mozilla.org/en-US/firefox/addon/fireftp/
If I click on Add to Firefox:
1.) "Upgrade Firefox" button is useless and leads the user confusingly back to "upgrade" to version 3.6.
2.) "older versions" takes the user to the versions page where the user is forced to dig around looking for a compatible version.

Normal users who are still using the latest version of Firefox (3.6) should be offered the latest version for available for 3.6.  Beta users of Firefox (4.0) should be the outliers, not the norm.
This is still broken, in my opinion - what did this bug actually change?  See also my rant in bug 615399

Comment 12

8 years ago
Or maybe I'm confused - is this bug fixed but not pushed live yet?
(Reporter)

Comment 13

8 years ago
This will be going live on Thursday.

Comment 14

8 years ago
Blah, sorry for the noise then - I guess I released too early :-/

Updated

8 years ago
Depends on: 640041
Here are the steps I used to verify.

* Install 1.0 of https://addons.allizom.org/en-US/firefox/addon/bug-611534/versions/?page=1#version-1.0 in Firefox 4.0 and Firefox 3.6.*
* check for updates

expected behavior:
version 2.0 is offered for 3.6.*
version 3.0 is offered for 4.0.*

actual behavior:
same as expected.

Marking this verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 16

8 years ago
Nice job on this Andy; it works exactly like I wanted it to.

Mime, this is fixed for FireFTP in production now.

Comment 17

8 years ago
Thanks, guys!

Comment 18

8 years ago
Are there any docs on this feature?

If we set Firebug 1.7b2 to minVersion 4.0, then FF 3.6 users will not be offered any update correct? Specifically they won't see "here's an update, but oh it's not compatible with 3.6" right?

Comment 19

8 years ago
Firebug tried the minVersion, I want to explain why it does not work for us.

Firebug has two versions at any one time; each version supports two Firefox versions.  So 
   1.6 supports FF3.5 and FF3.6
   1.7 supports FF3.6 and FF4.0.
This overlap is essential for us and for our users. For firebug dev we must have way to triage bugs between Firebug changes and Firefox changes. So we need to be able to test 1.7 against stable 3.6 while FF4.0 is under development. For users they need rock solid debugger on the mainstream Firefox: they need 1.6 until 1.7 has been completely shaken down, typically six weeks after the .0 release (ie six weeks after FF4.0 ships).

If we put minVersion 3.6 on 1.7 and push updates to AMO, then our 3.6 users get pushed on to 1.7: Not good.

If we put minVersion 4.0 on 1.7 and put it up on AMO, then our 3.6 users get offered an update that fails: Not good.

These outcomes are not acceptable, we need a better solution.

What we want is the ability to offer specific versions of Firebug for specific versions of Firefox.  We want a real beta channel, not a mysterious link on the other versions page. When a user comes to AMO they should be offered a recommended version for their browser (1.6 for 3.6, 1.7 for 4.0 on the stable channel and 1.7 for 4.0 and 1.8 for trunk on the beta channel).

Comment 20

8 years ago
(In reply to comment #19)
> If we put minVersion 3.6 on 1.7 and push updates to AMO, then our 3.6 users get
> pushed on to 1.7: Not good.
> 
> If we put minVersion 4.0 on 1.7 and put it up on AMO, then our 3.6 users get
> offered an update that fails: Not good.

These statements I made about AMO are incorrect as far as I know. I was actually testing against getfirebug.com and the problem was the update.rdf file.

The situation on AMO currently:
   FF 3.6 -> Firebug 1.6.2 good
   FF 4.0 -> "Not available for Firefox 4.0" not good.
Firebug is not listed when I search in about:addons, though lots of Firebug extensions are listed.  I don't know the cause of these issues.
(In reply to comment #20)

We filter already installed or incompatible add-ons; you are likely seeing the former.

Comment 22

8 years ago
I did my tests in a new profile
(In reply to comment #20)
> The situation on AMO currently:
>    FF 3.6 -> Firebug 1.6.2 good
>    FF 4.0 -> "Not available for Firefox 4.0" not good.
> Firebug is not listed when I search in about:addons, though lots of Firebug
> extensions are listed.  I don't know the cause of these issues.

Your 1.7 versions are marked as beta versions, so they'll never show up in the main section. If you upload a 1.7 that isn't a beta that supports 4.0 it will show up for 4.0 users, while 1.6.2 will continue to be offered to 3.6 users.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.