If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add Support for editable maxAppVer/OS for existing versions

RESOLVED FIXED in 1.0

Status

addons.mozilla.org Graveyard
Developer Pages
--
enhancement
RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: alanjstr, Assigned: wolf)

Tracking

Details

(Whiteboard: beta, URL)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
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.  
(Assignee)

Comment 2

13 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → WONTFIX
(Reporter)

Comment 3

13 years ago
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?  
(Assignee)

Comment 4

13 years ago
(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.
(Reporter)

Comment 5

13 years ago
http://www.mozilla.org/projects/firefox/extensions/
http://www.mozilla.org/projects/firefox/extensions/update.html 
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Updated

13 years ago
Status: REOPENED → NEW
(Assignee)

Comment 6

13 years ago
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. :-)
Summary: Allow maxVer to be editable → Add Support for editable maxAppVer for existing versions
(Reporter)

Comment 7

13 years ago
Someone posted them to the forum.  

Comment 8

13 years ago
REF: Comment #5

I posted this on the mozillazine forum but haven't gotten a definitive answer;
hopefully, someone here can answer it.

I'm a little confused as to how to specify the updateLink for a theme. In the
docs above, it shows how its done with an extension, as such: 

<em:updateLink>http://www.mysite.com/fooextension2.3.xpi</em:updateLink>  

However, since themes are required to be in JAR format, not XPI, would it simply
be: 

<em:updateLink>http://www.mysite.com/footheme2.3.jar</em:updateLink>  

? The reason I ask is that XPIs will self-install when served but JARs require
the javascript software installation trigger. 

Am I reading too much into this or, more likely, am I missing something?
(Reporter)

Updated

13 years ago
Flags: blocking-aviary1.0?
(Assignee)

Comment 9

13 years ago
*** Bug 254610 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Summary: Add Support for editable maxAppVer for existing versions → Add Support for editable maxAppVer/OS for existing versions
(Assignee)

Comment 10

13 years ago
*** Bug 252633 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 11

13 years ago
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. :-)
(Assignee)

Comment 12

13 years ago
*** Bug 255310 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

13 years ago
Whiteboard: fixed-development

Updated

13 years ago
Whiteboard: fixed-development → fixed-development - serverside
(Assignee)

Updated

13 years ago
Whiteboard: fixed-development - serverside → fixed-beta

Updated

13 years ago
Whiteboard: fixed-beta → fixed-beta u.m.o
(Assignee)

Comment 13

13 years ago
Its in update-beta but update-beta isn't going to make 1.0.

blocking-
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Whiteboard: fixed-beta u.m.o → fixed-beta
(Assignee)

Comment 14

13 years ago
Bulk Moving Developer Control Panel bugs to new component.
(Filter: massdevcpspam)
Component: Update → Developers
Product: mozilla.org → Update
Version: other → unspecified
(Reporter)

Comment 15

13 years ago
Mass-resolving bugs that have been fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

13 years ago
Sorry for the bugspam, reopening bugs wrongly marked as resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

13 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Updated

13 years ago
Target Milestone: --- → 1.0
(Assignee)

Updated

13 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: fixed-beta → beta
Version: unspecified → 0.9
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.