250756 - install.rdf should support nightly builds

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Ben Basson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

We already have support for using syntax such as 0.9.0+ for maxVersion, but this
is incredibly vague, given the nature of nightlies. It would be a great
addition, if possible, to be able to specify multiple minBuild and maxBuild
dates (YYYYMMDDXX, where XX can be replaced with T or B or both, for Trunk and
Branch) if the extension is known not to work, or becomes irrelevant.

A prime example of why this would be a great (optional) addition to install.rdf
would be my extension Find Statusbar. It is no longer useful after 20040707
Branch, due to the Find Toolbar.

I'd leave finetuning of the details to a greater person than myself, but this is
a rough start. I'm guessing this will be WONTFIXed due to the fact that
nightlies are for testing, but there's no reason why we need to risk destroying
tester profiles any more than regular end user profiles due to extension
incompatibility/irrelevance.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Nickolay_Ponomarev]

Ben, I suggest that you close this bug, since the "We already have support for
using syntax such as 0.9.0+ for maxVersion" statement is no longer true (you
know, new app.extensions.version pref is x.y until a major change happens, after
which it is increased if I understood the idea correctly).

Comment 2

[alanjstr]

Nightlies have a useragent of 1.0+.  Maybe we should call them 1.0+.yyyymmdd
instead.  Any plan that we come up with must be compatible with UMO.  

Comment 3

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

Ben, the Extension Manager supports this and if you still want this bug to be fixed I suggest changing the component to get the version data / format that would accomplish this supplied to the Extension Manager (e.g. nsIXULAppInfo QI'd to nsIXULRuntime). I personally think this would be overkill for most cases.

Comment 4

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

Resolving -> wontfix though as far as the EM goes this is wfm. If you would still like this the app version per comment #3 will need to support nightly builds and once that is done it should just work with no changes to the EM.