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

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Add-on Validation, defect)

Description

[Axel Hecht [:Pike]]

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

[Matt Basta [:basta]]

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/

Comment 2

[Axel Hecht [:Pike]]

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.

Comment 3

[Eduardo Trápani]

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/

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 5

[Eduardo Trápani]

Thanks.  I filed Bug 797455.