Support Extension Compatibility Ranges (multiple minVersion/maxVersion pairs)

NEW
Unassigned

Status

()

Toolkit
Add-ons Manager
12 years ago
3 years ago

People

(Reporter: Ben Goodger (use ben at mozilla dot org for email), Unassigned)

Tracking

unspecified
mozilla2.0
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox2 -

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [Triaged 9/2/12])

Attachments

(1 attachment)

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

Updated

11 years ago
Summary: Support Extension Compatibility Ranges → Support multiple extension version compatibility ranges
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.)
Flags: blocking-firefox2?
Summary: Support multiple extension version compatibility ranges → Support Extension Compatibility Ranges
Sorry for the spam, I thought bugzilla was bluffing.
Summary: Support Extension Compatibility Ranges → Support Extension Compatibility Ranges (multiple minVersion/maxVersion pairs)
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.
I didn't state it directly but the RDF format should not have to change
Blocks: 342963

Comment 7

11 years ago
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

11 years ago
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.
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".

Updated

11 years ago
Flags: blocking-firefox2? → blocking-firefox2+
--> Firefox 2 beta 2
Target Milestone: --- → Firefox 2 beta2
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.
Blocks: 343779

Comment 12

11 years ago
->RS
Assignee: nobody → robert.bugzilla

Updated

11 years ago
Whiteboard: [at risk]

Comment 13

11 years ago
Don't think this is gonna make it - pulling from the list
Flags: blocking-firefox2+ → blocking-firefox2-
Whiteboard: [at risk]
Target Milestone: Firefox 2 beta2 → Firefox 3
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.

Depends on: 394286
Keywords: uiwanted
Ignoring the UI issue the actual work of supporting multiple targetApplication entries will actually be done by the fix I have for bug 394300
Depends on: 394300
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.
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.
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.
Will take a closer look at this after M8
Assignee: robert.bugzilla → dtownsend
Target Milestone: Firefox 3 → Firefox 3 M9
Still a potential but pushing back at this stage.
Keywords: uiwanted
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Created attachment 282678 [details] [diff] [review]
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.

Updated

10 years ago
Assignee: dtownsend → nobody
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
Target Milestone: mozilla1.9beta2 → ---
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.
Yes this is something I want to do and may happen not long after Firefox 3.1
Duplicate of this bug: 481718
Target Milestone: --- → mozilla1.9.2
Target Milestone: mozilla1.9.2 → mozilla1.9.3
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.
blocking2.0: --- → ?

Updated

8 years ago
blocking2.0: ? → -
No longer blocks: 343779
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).
Whiteboard: [Triaged 9/2/12]
You need to log in before you can comment on or make changes to this bug.