User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 Build ID: 20120628060610 Steps to reproduce: Use latest nightly or UX build (16.0a1). Visit a theme page, where the theme is compatible to latest nightlys, e.g. https://addons.mozilla.org/addon/noia-4/ Actual results: Site displays "used Firefox version is 16.0" and marks theme as not compatible. Expected results: Site should recognize version as 16.0a1, mark theme as compatible and allow installation.
Nightly 17.0a1 shows same wrong behavior. While on 17.0a1 visit https://addons.mozilla.org/addon/noia-4/versions/ v1.7.3 is marked as not compatible to >17.0< and there is no way to force 'install anyway' or to download it manually, although it is compatible to 17.0a1! The only workaround for this issue is to download an 'older' version of Firefox (<17.0a1), install the theme and reinstall 17.0a1.
This was caused by bug 728831 and it affects add-ons that are not extensions on the Aurora and Nightly channels. One possibility would be just to add 17.0 as a valid maxVersion. The other possibility would be for AMO to know which versions are in Aurora and Nightly at the time, and ignore the *a1 and *a1 in the maxVersion.
Thanks for reply. Both solutions sound great, but I guess the first one, allowing 17.0 instead of 17.0aX for all uploaded add-ons, would cause less work and less checks.
Wil, what do you think? Should we just consider 17.0a1 the same as 17.0 now that Firefox doesn't publish the build information? I can just add 17.0 as a possible maxVersion, but I'd like to know if there are any plans to change AMO to adjust to this change.
(In reply to Aris from comment #3) > Thanks for reply. Both solutions sound great, but I guess the first one, > allowing 17.0 instead of 17.0aX for all uploaded add-ons, would cause less > work and less checks. Yeah, let's just do that. I just added 21.0 as a valid maxVersion, and will make sure future version upgrades include the corresponding Nightly version.