283803 - Version sorting and storage needs to be standardized

Status: RESOLVED FIXED

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

Description

[Anton P.]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.6) Gecko/20050223 Lightningfly/1.0.1 (Firefox/1.0.1 polymorph)
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.6) Gecko/20050223 Lightningfly/1.0.1 (Firefox/1.0.1 polymorph)

Background: the document "Extension Versioning, Update and Compatibility" at
http://www.mozilla.org/projects/firefox/extensions/update.html states that the
versioning format is major.minor.release.build[+], but the preference
app.extensions.version determines whether or not a given extension is compatible
with a given build, and this pref is ordinarily of the form major.minor. Hence
my extension with a max Firefox version of 1.0 is still compatible with Firefox
1.0.1.

However, when changing my selection criteria on Mozilla Update (eg on the URL
provided, although any page will do) from Firefox 1.0 (which seems to be the
current default when you first visit the page---how is this determined?) to
Auto-Detect, only one extension is listed, and apparently only because it has an
illegal max Fx version of 1.1.

Moreover, when changing the criteria to Firefox 1.0+ only two extensions are
listed, because they have set their max version to be 1.0+ or 1.1.

This is incorrect. By the rules in the document just described, all extensions
whose max version is 1.0 should also be listed when one searches for Fx 1.0+
extensions, and when one uses Auto-detect while browsing with any version of Fx
of the form 1.0.whatever.whatever.

[NB It is not specified in this document what the purpose of the "+" is. Indeed,
it is clearly stated that one should not set the max Fx version to be greater
than the current Fx release. So to me---and perhaps I'm misunderstanding things
here---the "+" is meaningless.]



Reproducible: Always

Steps to Reproduce:
1. Visit Mozilla Update
2. Choose a Firefox Extensions category, such as Tabbed Browsing
3. Change the Versions criteria to auto-detect (if you're using Fx 1.0.1) or to
Firefox 1.0+
Actual Results:  
Extensions whose max Fx version is 1.0 do not appear in the results.

Expected Results:  
Listed such extension, since the document described above states that:

[Suppose] "For example, Firefox 1.1 ships, with app.extensions.version set to
"1.1". Hypothetical security firedrills cause 1.1.1 and 1.1.2 releases, but both
of these follow-ons still have app.extensions.version set to "1.1" - since there
are no changes in the subminor releases that cause extension incompatibility, we
don't want to break Extensions compatible with 1.1."

Comment 1

[alanjstr]

At least part of the problem is bug 246746.  As for your interpretation of "the
rules" ... 1.0+ is being used to represent Trunk, not branch.  So if you're
looking for 1.0.1 compatible items, you should stick to 1.0.  I'll look into
putting 1.0.1 on the site, but no promises.

Comment 2

[Anton P.]

I'm not sure I fully understand your explanation, and I'm fairly certain that 
most regular users of Mozilla Update won't understand the intricacies of the 
versioning system either. I raise this bug simply because, from the point of 
view of the average user, the Mozilla Update system is confusing. If they are 
using Firefox 1.0.1 then they can be forgiven for expecting the "Firefox 1.0+" 
and "Auto-detect" criteria to give them all compatible extensions. In fact, if 
it were me in that position I would deliberately pick "Firefox 1.0+" 
over "Firefox 1.0" because to me it best describes the browser I am using.

In my mind, this issue boils down to a poor user interface for Mozilla Update, 
not a problem with the versioning system. It needs to be made clearer for the 
average user which criterion is appropriate for their current browser. Part of 
the solution might indeed be to fix the problems with the auto-detection 
script. However, the user should also be warned if they choose an inappropriate 
criterion. Perhaps some warning is required which describes the real meaning 
of "Firefox 1.0+".

Comment 3

[Michael Morgan [:morgamic]]

Difficulties arose when trying to implement the c++ versioning standards while also needing to perform scalable sorting and selecting in SQL.

Originally, the web application across the board was implemented assuming that storing these version in varchar fields would suffice.

Many bugs have been filed about incorrect sorting and versioning.  Some have been fixed by relying on primary keys, dates, or other factors that affect and determine what is "the lastest version".

The challenge will be balancing the unconventional versioning used by the algorithm and what is offered by SQL.

Comment 4

[Michael Morgan [:morgamic]]

Renaming bug -- while Anton's comments touched on a UI-centric problem, this is dealing with more than UI -- particularly how versions are stored and sorted during retrieval.

Comment 5

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 6

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

(In reply to comment #3)
> Difficulties arose when trying to implement the c++ versioning standards while
> also needing to perform scalable sorting and selecting in SQL.
> 
> Originally, the web application across the board was implemented assuming that
> storing these version in varchar fields would suffice.
> 
> Many bugs have been filed about incorrect sorting and versioning.  Some have
> been fixed by relying on primary keys, dates, or other factors that affect and
> determine what is "the lastest version".
> 
> The challenge will be balancing the unconventional versioning used by the
> algorithm and what is offered by SQL.

I'm not that worried about performance of the version sort, given how infrequently the input (and therefore result) changes for a given extension.  We can cache the sort order in a number of ways, and recompute it only when a version is added or removed, so I think that correctness should trump here.

For the selection case, I'm not sure what searches we need to perform, so it's hard to say what we need to cache or control.  We might still be up the creek!

Comment 7

[Cameron]

We no longer allow specifying a version in searches (although there's a bug on it - bug 347202) 

Bug 292138 is fixed

1.8.1 no longer uses the app.extensions.version pref (bug 330895)

So where's this bug at?

Comment 8

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

I think this bug is fixed, since all the uses in Remora are consistent now.