During the 015 tenant->project migration, any FKs that reference the (about to be deleted) tenant table are switched to point at the new project table. However, for sqlite, the group_project_metadata table was missed and remains pointing at the old tenant table. Migrations for MySQL and Postgresql are not affected and correctly change the FKs.
This means that any future calls to load that table in migrations scripts using sqlite fails trying to load the (now deleted) tenant table. This first becomes a real problem in migration script 028 which attempts to re-structure the roles metadata - and hence this does not support migration via sqlite.
Our options are:
a) Write a special migration that goes under the cover and tries to fix up the FK for sqlite
b) We stop supporting migrations with sqlite
The real issue here is that you are limited by what kind of table modifications are supported with sqlite - which often requires a separate code path for any such table altering. It is this separate code path that was wrong in 015.
How fast can we stop supporting sqlite migrations? ;)