305162 - Support new app versions

Status: RESOLVED DUPLICATE of bug 313605

(addons.mozilla.org Graveyard :: Developer Pages, defect, P1)

Description

[Ed Hume]

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.

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

*** This bug has been marked as a duplicate of 304857 ***

Comment 2

[alanjstr]

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.

Comment 3

[Ed Hume]

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. 

Comment 4

[alanjstr]

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)

Comment 5

[Colin Ogilvie [:cso]]

I don't currently have much time to look at this for a few weeks.

Comment 6

[alanjstr]

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 1.6.0.0 for a1
and 1.6.0.1 for a2

Comment 7

[Mike Connor [:mconnor]]

the new version comparison code needs to land in AMO for this to work.  The old
code doesn't do non-numeric.

Comment 8

[alanjstr]

Yeah, but the UI needs to change, too.  I'll need to check the schema.  Do we
store these as separate ints?

Comment 9

[Ed Hume]

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.

Comment 10

[alanjstr]

 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

Comment 11

[alanjstr]

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

Comment 12

[Michael Morgan [:morgamic]]

This bug was resolved/addressed in bug 313605.  Please direct conversation there.

*** This bug has been marked as a duplicate of 313605 ***