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.

How do we make a programmatic mapping from fuzzy application version strings to real ones?

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 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. Not all versions of all products are actually in this table. Should this table be made more complete? What would be the source of the complete data?

Versions from appversions

For the product Firefox only

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.*

The Solutions

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

1 -- Drop Versions

If a version has bad min or max application version strings, drop that version from the migration.

What if an addon then has no version entries at all?

That leaves the clean up the appversions version strings question unanswered...

2 -- A Mapping

Since the migration script is a one-off program (only used once and then thrown away) making a complicated and flexible-intelligent-fuzzy-version-conversion-system isn't necessary. There aren't that many distinct erroneous versions. Manually make a map of Max&MinVer strings to the versions available in the appversions table. When encountering a mystery version, look it up and proceed.

Should the appversions table be cleaned up first? There doesn't seem to be much rhyme or reason for the use of ".x" ".*" and "+".

I've only examined this problem for the product Firefox. Does this solution scale when adding the other products?

Anyone volunteering to help fill in this table?

...for the product Firefox only....

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