In order to make commits that change the schema as discoverable is possible, I'd propose the following guidelines: * Update RELEASE-NOTES to briefly mention the change (this is not always necessary for follow up changes within the same release, since people upgrading don't care about intra-release changes). * Include "[Schema]" near the beginning of the first line of the commit. * Mention the names of the tables that the schema was changed for as a bullet point in the commit summary.

Also, changes should always allow for a temporary rollback strategy when people upgrade from one major MediaWiki version to the next. The schema for version X+1 should work with the version X code. Mostly, this just involves doing additions in version X+1 and removals in version X+2 or higher. More specifically: * New tables are fine * New columns are fine *as long as* they have default values (also one should check for code that does SELECT * and does for loops on all fields, which should be avoided to begin with) * New indexes are fine (note that adding a new column and a unique index on it can cause problems even with DEFAULT NULL for some non-mysql DBMS) * Table removal is fine if it already wasn't used in the previous MediaWiki version and any data worth migrating is already first migrated in update.php with a "logged update" * Column removal is fine if it already wasn't used in the previous MediaWiki version and any data worth migrating is already first migrated in update.php with a "logged update" * Index removal is fine if it already wasn't used in the previous MediaWiki version (one could also remove index A and add index B which also handles the queries that used A *provided* there are no FORCE INDEX A statements used by MediaWiki) * Column changes that just fix prior problems or just expand the range of values are fine (e.g int => bigint, NOT NULL => NULL, varchar => blob), as long as it works with the previous MediaWiki version * Index changes that are fine as long as it works with the previous MediaWiki version (e.g. making an index not used for sorting go from (field_sha1) to (field_sha1(8)), or doing changing and index from (field_a) to (field_a,field_b)).

The reason I say "temporary rollback" is that during such a rollback it might be OK for certain problems to exists. For example, in the past the data stuffed in page_restrictions was moved to a new page_restrictions table. Of course if some one upgraded for a while, and then rolled back, newly protected pages would magically become unprotected (until the upgrade was re-attempted or an admin re-protected the pages). The degree to which these problems are acceptable depends on: a) The likelihood of a rollback being needed (larger with more complex changes) b) Whether a rollback would be likely to only last for a brief time for a hotfix or would be likely to last a long time (more so with more complex changes) c) How annoying the problem would be

I'd say that those things should be measured on a case-by-case basis. In some cases, version X+1 should write to both the old and new style locations if the risk is too high.

-- View this message in context: http://wikimedia.7.n6.nabble.com/Commits-that-make-schema-changes-tp4990111.... Sent from the Wikipedia Developers mailing list archive at Nabble.com.