301236 - Support Extension Compatibility Ranges (multiple minVersion/maxVersion pairs)

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

Currently you can specify support for just one target application range in
install.rdf:

    <em:targetApplication>
      <!-- Firefox -->
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>1.0</em:minVersion>
        <em:maxVersion>1.1</em:maxVersion>
      </Description>
    </em:targetApplication>

... it may become necessary to say an item supports multiple ranges of version
compatibility of the same application, not just multiple applications, so it
would be nice if the EM would check for N instances of targetApplication
resources with em:id matching the current application and verify compatibility
with each of the specified ranges. This allows an extension to target multiple
branches.

Comment 1

[Dave Townsend [:mossop]]

This has really become necessary now with the branch. I have an extension that
supports all firefox's from 1.0 up to the current trunk which is 1.6a1. Of
course that range includes 1.5, the next release which isnt out.

I have two options, either do one extension with minversion 1.0 and maxversion
1.6a1, but this means Im saying its compatible with an unreleased version which
I think is a bad thing. Or I could do two different packages of the same
extension, this will be time consuming for me, no doubt confusing for users and
I imagine unsupported at UMO.

This bug should also apply to the update rdf files, they would need ranges too.

Comment 2

[Robert Strong (they/them - no direct email)]

Blacklisting supports ranges as specified on http://wiki.mozilla.org/Firefox:1.5_Extension_Manager_Blacklist

I am willing to take this on but I doubt I will have time before 2.0. As implied by the update rdf requiring this change, so will the update rdf output on A.M.O. - it would also make sense to fix Bug 299716 at the same time since we will probably want to add new arcs to the update rdf datasource to fix this and Bug 299716... at least to fix them both in a clean manner.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I'm quite interested in this for Fx2, because right now we have no good way for developers to do the "right thing" with respect to supporting 1.5.0.x (via maxVersion="1.5.0.*") and also support Firefox 2.  Developers will have to say minVersion="1.5"/maxVersion="2.0.*" to work in both places, but that means that we lose the important 1.5.1.x-for-unavoidable-incompat capability in our maintenance releases.

Do we need to change the format of the RDF, or can we just support multiple <app> stanzas, each identical except for different max/min pairs?  To be clear, I'm looking for a minimal fix for the Fx2 timeframe to avoid the versioning problem I describe above, so I would strongly prefer to avoid entraining other architectural changes for the usual reasons of risk mitigation and time constraints.

(If we get this sorted out in an RDF-compatible way, it would also be good to look at taking such a fix on the 1.5.0.x branch for consistency and conservation of developer brain-print.)

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Sorry for the spam, I thought bugzilla was bluffing.

Comment 5

[Robert Strong (they/them - no direct email)]

We would have to implement new methods due to the API freeze. I am planning on doing the groundwork for this hopefully this week in bug 324121.

Comment 6

[Robert Strong (they/them - no direct email)]

I didn't state it directly but the RDF format should not have to change

Comment 7

[Ed Hume]

I just tried to upload a theme with a maxversion = 3.0. AMO will not accept it. 

This bug is not academic any more.

Comment 8

[Ed Hume]

Worse yet: The maxversion allowed is 2.0.0.a3. I HOPE that when 2.0.0.bs is released, Users will be able to use my themes. I would hate to have to upgrade all three of them to chase Firefox appversions.

BTW - if this is the wrong bug to bring up this point, email me directly. Thanks.

Comment 9

[Robert Strong (they/them - no direct email)]

The AMO issue with not having version numbers in its database for ext,/theme authors to use is not this bug. This bug is already well known and well defined... additional comments don't provide value unless it is along the lines of "I'll fix this".

Comment 10

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

--> Firefox 2 beta 2

Comment 11

[Robert Strong (they/them - no direct email)]

Fixing this is a rather substantial change and I doubt this would get a1.8.1+. I'll be doing the prep work for this as part of bug 324121 and if the additional changes for this bug are not too crazy for Firefox 2.0 I'll try to fix this as well.

Comment 12

[Mike Schroepfer]

->RS

Comment 13

[Mike Schroepfer]

Don't think this is gonna make it - pulling from the list

Comment 14

[Dave Townsend [:mossop]]

This looks pretty simple to do in terms of the backend work. The major issue is the UI presented when the extension is incompatible. Going to add the details to bug 394286 since we are looking at that message there.

Comment 15

[Dave Townsend [:mossop]]

Ignoring the UI issue the actual work of supporting multiple targetApplication entries will actually be done by the fix I have for bug 394300

Comment 16

[Robert Strong (they/them - no direct email)]

Dave, when we perform a compatibility update the ideal would be to update the individual targetApp minVersion and maxVersion in both the extensions datasource and the install manifest as we do today which is to say the least problematic when adding support for ranges. Perhaps find a match for the targetApp ID as well as the minVersion then updating the corresponding ones in the extensions datasource and the install manifest? note: we only update install manifests for add-ons installed in the profile dir intentionally.

Comment 17

[Dave Townsend [:mossop]]

Do we need to match on minVersion, or should we just update the targetApp in the ds that matches the current app with the one from the update.rdf that matches the current app? I think this should work presuming we don't want to deal with overlapping ranges?

As it happens we are now accepting multiple version ranges for target apps in update manifests as the result of a few other bugs I believe. Just only listening to the first one that matches the app and updating the ds with that.

Comment 18

[Robert Strong (they/them - no direct email)]

This might be acceptable... my main concern is with going from one version of the app to the next. I'm tempted to go with just setting the compatible targetApp min and max but I'd like to know as many of the conditions as possible where this won't be ideal for the user experience.

Comment 19

[Dave Townsend [:mossop]]

Will take a closer look at this after M8

Comment 20

[Dave Townsend [:mossop]]

Still a potential but pushing back at this stage.

Comment 21

[Dave Townsend [:mossop]]

Attachment: unit tests (wip)

Just for the sake of keeping these somewhere safe for now these are hte unit tests I have worked up to test this feature.

Comment 22

[Michael Morgan [:morgamic]]

Is this still on the map?  There are 4-5 AMO bugs surrounding this but if it's not a priority I'm going to close them.

Comment 23

[Dave Townsend [:mossop]]

Yes this is something I want to do and may happen not long after Firefox 3.1

Comment 25

[Mark Banner (:standard8)]

I know this is something that Dave wants to work on, and is targeted for 1.9.3 but I really am starting to think that this is now a requirement for Firefox, Thunderbird and other gecko apps as we move forward.

In the Thunderbird 3 cycle I have seen several extensions that claim support for Thunderbird 3 final, when in fact they were uploaded some months before the last beta, and its obvious the extension reporter wanted to support the next development branch at the time.

With the fact that we're now looking at multiple, short-lived branches, this is going to be happening much more frequently, and we should be encouraging extension authors not to claim compatibility to something they haven't tested, rather than forcing them to make a decision for stable-only and not supporting trunk alpha/betas (and getting feedback), or supporting both and hope it doesn't break (and if not, then also hope they get time to update it) when the application gets to the final release.

Therefore requesting blocking1.9.3 as I think this is issue that we really need resolving to help our extension authors and encourage correct compatibility ranges.

Comment 26

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Technically still an issue in the new Add-ons Manager. Not entirely convinced of it's usefulness though, especially considering compatible-by-default (which, admittedly, not all apps will enable). And it would require a DB schema change (the targetApplication table doesn't have a per-row id).

Comment 27

[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.