Change Details

Before fully switching to the new schema, we should exercise the new retrieval code. This means setting $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW; This keeps writing to the old schema as well, so we can still easily back out of the migration. NOTE: we'll want to have this enabled on the live systems for a while before releasing it as the default for 3rd party installs, see T198561. But we'll want to have this as the default on master / for CI before enabling it on the live systems, see T198561. NOTE: **This enables the usage of extra slots on the live systems!** If we are forced to roll this back, we will lose access to the content of the new, extra slots. Rolling forward again would restore that access for old revisions, but extra cleanup would be needed to then again associate that content with newer revisions, made while the change was rolled back. Users should avoid large-scale edits that would be broken by a rollback until we're reasonably sure a rollback isn't going to be needed. WARNING: Because of cross-wiki revision access, this can only be done an ANY system on the cluster once ALL systems on the cluster write the new schema.

Before fully switching to the new schema, we should exercise the new retrieval code. This means setting $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW; This keeps writing to the old schema as well, so we can still easily back out of the migration. NOTE: we'll want to have this enabled on the live systems for a while before releasing it as the default for 3rd party installs with #MW-1.32-release. But we'll want to have this as the default on master / for CI before enabling it on the live systems, see T198561. NOTE: **This enables the usage of extra slots on the live systems!** If we are forced to roll this back, we will lose access to the content of the new, extra slots. Rolling forward again would restore that access for old revisions, but extra cleanup would be needed to then again associate that content with newer revisions, made while the change was rolled back. Users should avoid large-scale edits that would be broken by a rollback until we're reasonably sure a rollback isn't going to be needed. WARNING: Because of cross-wiki revision access, this can only be done an ANY system on the cluster once ALL systems on the cluster write the new schema.

Before fully switching to the new schema, we should exercise the new retrieval code. This means setting $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW; This keeps writing to the old schema as well, so we can still easily back out of the migration. NOTE: we'll want to have this enabled on the live systems for a while before releasing it as the default for 3rd party installs, see T198561 with #MW-1.32-release. But we'll want to have this as the default on master / for CI before enabling it on the live systems, see T198561. NOTE: **This enables the usage of extra slots on the live systems!** If we are forced to roll this back, we will lose access to the content of the new, extra slots. Rolling forward again would restore that access for old revisions, but extra cleanup would be needed to then again associate that content with newer revisions, made while the change was rolled back. Users should avoid large-scale edits that would be broken by a rollback until we're reasonably sure a rollback isn't going to be needed. WARNING: Because of cross-wiki revision access, this can only be done an ANY system on the cluster once ALL systems on the cluster write the new schema.