I already published the instructions that extension authors should update their extension maxVersion to 1.5.0.*, but AMO doesn't allow that yet. We need to 1) teach AMO about the .* syntax 2) use the administration interface to allow 1.5.0.*

Argh, bug 304857 isn't even fixed yet!

I really think this needs to block RC1; extension authors have no way to update the maxVersion number the way we documented they are supposed to.

Question: Will FF 1.0 make sense of "maxVersion=1.5.0.*"? If not, then do we need to allow 1.5.0.999 as a workaround?

If AMO allows "up to 1.5.0.*" then 1.5.0.999 will work just as well. But we should test this to make sure.

Is this bug well owned? Are we anywhere near a fix?

Asa, I'm working on this and should be finished this afternoon.

Patch to fix application versions in database and alleviate unnecessary errors when developers attempt to upload .xpi files with versions that are actually valid. Using the version comparison code (see bug 304857) is not feasible at this point because of how versions are stored. The next step (sometime after 1.5rc1 release) is to adjust how app versions are stored and completely reengineer how they are used in all instances of AMO. However, that extends past the scope of this bug, and what we need to accomplish in order to accomodate addon developers. Therefore, while using the comparison code would be optimal, it shouldn't be listed as a blocker since it doesn't actually prevent people from using AMO with 1.5.0.* applications. Of course, please discuss and correct me if I'm wrong -- that's just what I saw from reading through the code and examining what is in the database.

Checked in to branch.

*** Bug 305162 has been marked as a duplicate of this bug. ***

This patch in conjunction with database updates to set SubVer='final' on 1.x appVersions that have a blank SubVer will fix all additem.php-related bugs that have been reported since this initial blocker for 1.5.0.* appVersions was fixed.

*** Bug 315319 has been marked as a duplicate of this bug. ***

The initial 1.5.0.* vercomp issue was resolved, but I am reopening/relabeling this in order to verify that all non-1.5.0.* versions are working properly for extension developer submissions.

Comment on attachment 202301 [details] [diff] [review] Adjustment to make comparisons clearer and fix improper errors. r=me, subject to the regexp getting cleaned up

Cleaned up regexp and checked this in. Will be updating appversions in admin control panel, and should be live by 4pm.

Changes are live, and the database is updated. Coule someone please verify that extension uploads are working correctly? I was able to get things working with quite a few non-1.5.0.* versions using dummy extensions.

Thunderbird 1.5.0.* now works, but Sunbird 0.2+ and 0.3a1 (and possibly others) still do not. I mention this here because bug 315319 (specifically about the Sunbird app version problems) was marked as a duplicate of this bug. Thanks.

My ext has a maxVersion of 1.5.0.* for TB and 1.8 for Mozilla Suite. AMO complains about the suite's maxVersion. A couple of weeks ago this maxVersion was still accepted, as you can see from the many extensions listed as compatible with suite 1.8

Mozilla Suite 1.8 is now enabled as a public version. The Sunbird 0.2+ is in there now, but I'll have to figure how we're going to store 0.3a1 given that the versions in `applications` are int.int.int.char. I'll have to make an adjustment to the code again, then post an update here. Once we are taken care of there, we're going to have to dive in and change the schema and version handling to use the ported C++ algorithm in order to handle all of this properly, which will take about a week to complete.

This patch was applied. The Sunbird version issue may be solved by using internal versions for sunbird 0.3a1+, etc. as was done for 1.5rc1 (1.4) and 1.5rc2 (1.4.2). Arguably, it might be worth it to set targets for final versions -- since that is what addons should be tested for (as a goal) anyway. What I don't understand is why we test against 1.4.1 and then when 1.5 comes out on release day the database is instantly out of date, and some extensions need to be updated just because 1.4.1 existed at all.

(In reply to comment #19) > The Sunbird version issue may be solved by using > internal versions for sunbird 0.3a1+, etc. as was done for 1.5rc1 (1.4) and > 1.5rc2 (1.4.2). Thanks. I notice that Sunbird's list at https://addons.mozilla.org/faq.php has not changed. Previously that list didn't work. Does that list now work (i.e. are those the "internal versions")? If not, and that list just needs to be updated, could you please let us know what the "internal versions" are? Thanks again.

(In reply to comment #20) > I notice that Sunbird's list at https://addons.mozilla.org/faq.php has not > changed. Previously that list didn't work. Does that list now work (i.e. are > those the "internal versions")? If not, and that list just needs to be updated, > could you please let us know what the "internal versions" are? I'm sorry, I just remembered that the problem with that list was not from AMO's point of view; it was from Sunbird's point of view (i.e. Sunbird 0.3a1 will not allow you to install an extension that claims to be for 0.3.0.a1). So what are the "internal versions"? Thanks again.

I just noticed that I misread your statement that "The Sunbird version issue may be solved by ..." as "... has been solved by ...", and that you're specifically talking about future versions of Sunbird. So, is anything going to be done to allow extensions that currently support Sunbird to currently get accepted by AMO, or should we just take out Sunbird support until some future version of Sunbird is released? If there's no other reasonable solution, can't we just pretend that Sunbird is "not a Mozilla application", like Flock, until the mess gets straightened out? And therefore that AMO won't do a check against its versions? I don't mean to be a pain, but I've been holding off on submitting an update for an extension for about a week now, merely because AMO has suddenly stopped accepting Sunbird-supporting extensions. It's not even (mainly) a Sunbird extension; that just happens to be one of the several apps that it supports. So, if possible, I would greatly appreciate a hint on whether anything's going to happen on this in the reasonably near term, or if I should just stop supporting Sunbird. Again, I don't mean to be a pain, or to be complaining.

Hey Bob, I understand your frustration. We're not going to fix the version storage tomorrow. I wanted to choose internal versions to represent the new version of Sunbird that would work in AMO and let you sumbit your update. So -- the question is really a matter of what internal versions to use. We have total control over what that should be, so it's really just a matter of saying "0.3a1 == 0.3.1" or something arbitrary. Would that internal version work for you?

(In reply to comment #23) > So -- the question is really a matter of what internal versions to use. We > have total control over what that should be, so it's really just a matter of > saying "0.3a1 == 0.3.1" or something arbitrary. > > Would that internal version work for you? Anything would be fine with me, as long as it (A) works in Sunbird, and (B) works in AMO. I just tested 0.3.1 in Sunbird, and the extension installed fine. So that would be great. Thanks again.

Use 0.2.1 to represent 0.3a1.

(In reply to comment #25) > Use 0.2.1 to represent 0.3a1. > But Sunbird 0.3a1 won't allow an extension with a maxAppVersion of 0.2.1 to install.

Arg... right. Let's use 0.3.1 -- forgot about that.

(In reply to comment #27) > Arg... right. > > Let's use 0.3.1 -- forgot about that. That worked great, both in Sunbird and AMO. Thanks! Unfortunately, I still can't submit, due to the issue with Flock-supporting extensions being impossible to submit (bug 290642).