When a new version of Firefox is released, the extension author should be able to log in and change the maxVer listed. This should be a dropdown to limit the choices. Since the items in the dropdown are controlled by the admins, I don't think we need to have this change go into the queue for review. This applies to themes and other applications, too.
Initial version would be gathered from install.rdf, but have the values limited to those in our admin table. So even if someone puts a maxVer of 999 in their install.rdf, we would cap it at 0.9.
There is a reason the DB doesn't allow the author to touch the values without a file update.. this is per spec.. The recent resolved bug doesn't change this. They should be able to reinsert properly the same version and have the records update, and the file fix itself.. This may or may not require reapproval. Basically, it's to prevent DB --> file inconsistancies.. Say end-user Bob downloads updated Extension Y, the install.rdf is 0.8-0.9, the DB was updated to be 0.8-1.0.... Bob's using Fx 1.0.. Fx's EM will reject the extension. This is unintended, since the file should be just as 1.0 compatible as the author told the DB to be.
I disagree. Every time the latest version comes out, they'd have to re-upload all of their extensions and themes. That's silly, if they're still compatible. With both bugs that Ben has fixed, the internal compatibility version and the ability for an extension to not have to be updated, what's the point?
(In reply to comment #3) > I disagree. Every time the latest version comes out, they'd have to re-upload > all of their extensions and themes. That's silly, if they're still compatible. > With both bugs that Ben has fixed, the internal compatibility version and the > ability for an extension to not have to be updated, what's the point? Internal Compatibility Version... is basically a FVF entry for EM/TM to use for Extensions/Themes only... Say the app.extension.version is 0.9 in all versions 0.9.x.. then it works... app.version was left as 0.9 to achieve the same thing, and broke smartupdate, the 0.9.1 thinks 0.9.1 is an upgrade bug. My understanding is, app.extension.version will be incremented for major milestones, but not subminor ones, unless needed. whereas app.version should be updated for every version for smartupdate of the app. normally they'll be the same. The other bug fix is for already installed extensions only. Update isn't triggered when you try to install a non-compatible extension, as I dicussed in Comment #2. The feature is for end-users upgrading firefox, not a workaround for extension/theme authors to leave old install.rdf's in hosted XPIs.
OK.. Nice to see documentation on this. There's a couple of caveats but overall sounds doable.. It's on my list of things to do for the new admin panel. Thanks for the doc link. :-)
Someone posted them to the forum.
*** Bug 254610 has been marked as a duplicate of this bug. ***
*** Bug 252633 has been marked as a duplicate of this bug. ***
As part of this, it'd be a good idea to make sure the install.rdf data coming into the system is known versions, since Firefox checks with Update now. (This comes from Bug 255310) If the MaxVersion is unknown, assume the newest known, and if MinVersion, assume the oldest known. The rest, attempt to match. :-)
*** Bug 255310 has been marked as a duplicate of this bug. ***
Its in update-beta but update-beta isn't going to make 1.0. blocking-
Bulk Moving Developer Control Panel bugs to new component. (Filter: massdevcpspam)
Mass-resolving bugs that have been fixed on trunk.
Sorry for the bugspam, reopening bugs wrongly marked as resolved.