Version numbers like 15.0.* not accepted, but created in the build system for langpacks et al

RESOLVED FIXED

Status

addons.mozilla.org Graveyard
Add-on Validation
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: Pike, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
The build system creates a MOZ_APP_MAXVERSION which it uses to make in-tree add-ons compatible in http://mxr.mozilla.org/mozilla-central/source/configure.in#8364.

That's generating version numbers like 15.0.*, but those are not accepted on AMO.

Can we add those to the allowed version numbers?

Comment 1

5 years ago
Point release builds (even with wildcards) are not accepted because they are not exposed with the new rapid release model. There has not been a version number like that since Firefox 4.0.*. Presumably, the build system should instead generate version numbers like 10.* instead of 10.0.*. With rapid releases, I don't believe such a change would have negative repercussions.

Jorge: Please feel free to correct me on anything.


Here is the canonical list of valid app versions:

https://addons.mozilla.org/en-US/firefox/pages/appversions/
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

5 years ago
Sorry, but my Firefox reports as 15.0.1 right now. I don't know why we would reject an addon that suggests to be compatible with chem spills only.

CC release management, Alex, would you want to use 15.x for some chem spill that's less compatible that something you'd call 15.0.x?

Either way, we have these add-ons out there, and until a fix on the gecko side made it through the channels, I suggest that AMO accepts what we generate.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 3

5 years ago
This also affects the beta language language packs from the build system[1].  While you're at it, could you also add 16.0.*, ?

[1] https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0b5/win32/xpi/
I added 15.0.* and 16.0.* as valid appversions for Firefox as a temporary fix, but this needs to be fixed on the build side. We already settled with X.* as the standard maxVersion for add-ons that want to support a branch, and adding X.0.* will just cause unnecessary confusion.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Comment 5

5 years ago
Thanks.  I filed Bug 797455.
(Assignee)

Updated

2 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.