257699 - Some extensions have maxVersions greater than the current release version

Status: VERIFIED WONTFIX

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

Description

[Grey Nicholson (they/them)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3) Gecko/20040901 Firefox/1.0 PR (NOT FINAL)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3) Gecko/20040901 Firefox/1.0 PR (NOT FINAL)

Ben's extension versioning document
(http://www.mozilla.org/projects/firefox/extensions/update.html) says "You
should never set maxVersion greater than the current Firefox release."
"update.mozilla.org will not accept Extensions with maxVersion set to a version
newer than the newest Firefox release."

Some extensions on update.mozilla.org
(http://update.mozilla.org/extensions/showlist.php?numpg=50&version=1.0&submit=Update)
have maxVersions set to Firefox 1.0 or above.

The maxVersions should be set to 0.10 until 1.0 is imminent (some time around
1.0 RC2).

Showing extensions as being compatible with 1.0 or 1.1 will confuse users into
thinking these versions are available, especially given the use of "1.0 PR" to
describe 0.10.

Reproducible: Always
Steps to Reproduce:

Comment 1

[kevin fisher]

That would really suck because 1.0 PR isn't really 'releaesed' yet, so anyone
running a recent nightly would be pretty much screwed if they want to install
any extensions from UMO.

As a philosopical question behind this issue...
Why is it so important for UMO to be such heavy-handed version police on the
extensions it hosts?  Every time a version number is changed (release, preview
release, whatever) you'd have to get 180 themes and extensions repackaged for
(usually) the sole purpose of bumping an internal version number.  Especially
after 1.0 is out the door, how often would the basic underlying structure of
Firefox change enough to make re-writing extensions for compatability a necessity?

Why not let the theme/extension authors decide what maxVersion to give their
package, have UMO copy this value for their own records, then limit this UMO
copy (not the number in the package itself) to the current Firefox release. 
Then, when there is a Firefox version change, bump these UMO copies for all
themes/extensions with a greater than or equal packaged maxVersion value.  If
there are complaints of incompatability, then lower the value back to where it
was and notify the author of the issue.

Example:
--------
When Firefox 0.10 is the greatest release...
Extension_A maxVersion: "1.2" maxVersion on UMO: "0.10"
Extension_B maxVersion: "0.10" maxVersion on UMO: "0.10"
Extension_C maxVersion: "1.1" maxVersion on UMO: "0.10"

When Firefox 1.0 is the greatest release
Extension_A maxVersion: "1.2" maxVersion on UMO: "1.0"
Extension_B maxVersion: "0.10" maxVersion on UMO: "0.10"
Extension_C maxVersion: "1.1" maxVersion on UMO: "1.0"

When Firefox 1.1 is the greatest release, but Extension_A breaks...
Extension_A maxVersion: "1.2" maxVersion on UMO: "1.0"
Extension_B maxVersion: "0.10" maxVersion on UMO: "0.10"
Extension_C maxVersion: "1.1" maxVersion on UMO: "1.1"

Comment 2

[Wolf [:wolf]]

Firefox checks against the UMO database for compatibility when the file says its
incompatible. This is a new feature in 1.0PR.

The policy of requiring maxAppVer to not be greater than the current version, is
sound. It unreasonable to wait for complaints from end-users before determining
compatibility. Particularly when those incompatibilities can cause data loss.

Either way, this bug is about DB management. It assumes end-users have read a
technical document on how Firefox extensions are managed. Yes, some extensions
currently have maxVersions in the DB that're greater than current. Most of which
were accepted during intitial set-up only. Prior to the completion of Update's
operating policies for the editor staff.

Comment 3

[alanjstr]

Please see bug 251795 and the comments I have made over there.

Comment 4

[kevin fisher]

(In reply to comment #2)
> The policy of requiring maxAppVer to not be greater than the current version, is
> sound. It unreasonable to wait for complaints from end-users before determining
> compatibility. Particularly when those incompatibilities can cause data loss.

That policy is *anything* but sound.  UMO relies on the individual extension
developers' claims that their extensions are compatable.  There are absolutely
no processes in place to ensure extensions have actually been tested for
compatability outside of this very vulnerable 'honor system' (which hardly
qualifies as a 'process').  If the powers that be behind Firefox want to ensure
extension compatability with any degree of certainty, then they must take the
responsability of testing individual extensions upon themselves.

Comment 5

[Wolf [:wolf]]

(In reply to comment #4)
> That policy is *anything* but sound.  UMO relies on the individual extension
> developers' claims that their extensions are compatable. There are absolutely
> no processes in place to ensure extensions have actually been tested for
> compatability outside of this very vulnerable 'honor system' (which hardly
> qualifies as a 'process').

UMO presumes the claim of compatibility by the extension author to be correct,
particularly with older versions (I.E. 0.6-0.8 for Firefox, since those versions
are before the birth of update and there's not the resources available for
backwards compatibility verification testing). Update also has editors who are
required to verify compatibility w/ the current stable release when adding new
extensions, (assuming the author says its compatibile with the currrent stable
release). I'm working on strengthening the accountibility on those editors when
they say they've tested an extension. So therefore, approving an extension means
the approving editor is on-the-hook for reported compatibility issues (for the
platform they verified compatibility on). That work is Bug 256086.

Comment 6

[kevin fisher]

(In reply to comment #5)
> UMO presumes the claim of compatibility by the extension author to be correct...

That's a *huge* problem, in my opinion.  Sure, such a claim could be a good
limit for testing compatability, but I firmly believe placing the responsability
of UMO extension compatability claims on editors who review the various
extensions for compatability is the best way to go that I've heard so far.  And
it would fit quite well with the idea I posed in comment #1.

Anyway, there's a relatively good discussion of this sort of thing at Mozillazine.
Starting here: (http://forums.mozillazine.org/viewtopic.php?p=770740#770740)
So I'm not going to bug-spam a 'verified wontfix' (a resolution that I agree
with anyway) anymore. =)