Update:Remora Migration

The Application Version Problem

The decision to convert the applications_versions.min and applications_versions.max columns from strings into actual foreign keys into the appversions table presents a conversion problem. The original min and max version strings in the old database were not closely policed and do not necessarily map to actual application versions.

Discussion

Addon #1980 has two versions (both designated as version 1.0, but that is a different problem). The first version of the addon is for Firefox 1.0 through 1.6. Because 1.6 does not exist, migrating that version fails because there is no valid foreign key value for FF1.6. The second version of this addon is for Firefox 1.0 through 1.5.1. Well, that version of Firefox doesn't exist either, so that version fails to migrate.

Many of addon version entries have faulty version numbers.

Complicating this issue is the incompleteness of the appversions table. This table is populated by finding the unique entries in the original database's applications table.

Versions from appversions

version from appversions
0.8
0.9.x
1.0PR
0.10+
0.9.3
1.0
Deer Park
0.7
1.0.1
1.0.2
1.0.3
1.0.4
1.0.5
1.0.6
1.5b1
1.6a1
1.0.7
1.5b2
1.5.0.*
1.5
2.0b1
3.0a1
1.5.0.4
2.0a1
2.0a2
2.0a3
2.0
2.0.0.*

Versions from MinAppVer & MaxAppVer

ersions from MinAppVer & MaxAppVer
0.8
0.9
0.7
0.6
0.7+
0.8+
0.9.1+
0.10
0.9.3
0.9.0+
0.9+
1.0
0.10+
0.9.6
0.3
.9
1.0.1
1.0+
1.0.4
00.8
1.5
1.4
1.0.3
1.0.5
1.4.0
Deer Park
1.4.1
0.1
1.0.2
1.5*
1.0.6
1.5.0.*
1.0.7
1.5.0.4
0.80
1.6
0.9.x
1.0PR
2.0b1
2.0a1
2.0a2
2.0a3
0.9.2+
0.9.3+
0.10.1+
0.10.1
0.11
3.0a1
1.1
3.0
2.0
01.6
3.0.0.a1
1.6a1
2.0.0.b1
2.0.0.a3
2.0.0.*

'How do we make a programatic mapping from fuzzy application versions to real ones?'

The Solution

I'm quite open to having someone give some input into this section.