User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050818 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050818 Firefox/1.6a1 Current trunk builds are at version 1.6a1. Extensions and themes with any smaller maxversion (e.g. - 1.5) will not be installed. I understand that it is too early for maxversion 1.5, but is there a way to allow maxversion </= 1.0+ and maxversion =/> 1.6? Otherwide, we need to have UMO allow maxversion > 1.6 (e.g. - 1.6+).6.1 dna Reproducible: Always Steps to Reproduce: 1. Attempt to upload theme with browser maxversion 1.6+ in install.rdf Actual Results: Upload rejected by UMO. Expected Results: Upload accepted by UMO.
*** This bug has been marked as a duplicate of 304857 ***
1.5beta will be 1.4 internally and 1.6a1 will be 1.6a1. The client code was changed to support new versioning in Bug 300731. The 1.5 Release candidate(s) will check for version 1.4.1 (and 1.4.2 if necessary). The final release of Firefox and Thunderbird 1.5 will check for extension compatibility with version 1.5. Bug 304470, Bug 304472, Bug 304373, Bug 304474 are the bugs for bumping Thunderbird/Firefox on Branch/Trunk to 1.4 and 1.6a1, respectively.
I am not sure that the point of my opening this bug is addressed by marking it as a duplicate of bug 304857. The thrust of that bug is that the letter supplements have to be accepted. The thrust of this bug is that the version number 1.6 needs to be accepted. The trunk builds as tonight are accepting themes and extensions with a version number of 1.6etc. Having UMO accept 1.4a2 will not allow extensions and themes aimed at the current trunk builds to be posted. Only a having UMO accept a number of 1.6 will do that. That was/is the point. If you want to graft that onto 304857, then this bug will then be a dupe of that one, as amended. But not really until then.
I discussed it with CTho, which is why I reopened this bug. Colin seems to be the expert on getting the new ones typed in right (cause I always do it wrong)
I don't currently have much time to look at this for a few weeks.
Well, I added them, but it keeps eating the a1 part of the internal. I guess we never expected the internal to be non-numeric. We could go with 220.127.116.11 for a1 and 18.104.22.168 for a2
the new version comparison code needs to land in AMO for this to work. The old code doesn't do non-numeric.
Yeah, but the UI needs to change, too. I'll need to check the schema. Do we store these as separate ints?
It is now 2005-08-20-2321-EDT. I don't know what if any code changes you have made at UMO, so this is simply a report and NOT a complaint. I just tried uploading a version of a theme with maxversions variously set at 1.6a1, 1.6+, 1.5 and 1.5+. All were rejected. When maxversion was set at 1.0+, UMO accepted the theme.
Field Type AppID int(11) AppName varchar(30) Version varchar(10) major int(3) minor int(3) release int(3) build int(14) SubVer enum('a', 'b', 'final', '', '+') GUID varchar(50) int_version varchar(5) public_ver enum('YES', 'NO') shortname char(2) int_version needs to be expanded. Subver needs to be altered to handle things like a1: 1.6a1
*** Bug 308994 has been marked as a duplicate of this bug. ***
This bug was resolved/addressed in bug 313605. Please direct conversation there. *** This bug has been marked as a duplicate of 313605 ***