Hi everyone,
As we do more frequent deploys, it's going to become critical that we
get database schema changes correct, and that we do so in a way that
gives us time to prepare for said changes and roll back to old
versions of the software should a deploy go poorly. This applies both
to MediaWiki core and to WMF-deployed extensions.
I'd like to propose that we make the following standard practice:
1. All schema changes must go through a period of being optional.
For example, instead of changing the format of a column, create a new
column, make all writes happen to the old and new column (if it
exists) and deprecate use of the old column. Check if the new column
exists before blindly assuming that it does. Only eliminate support
for the old column after it's clear the schema migration has happened
and there's no chance that we'll need to roll back to the old version
of the software.
2. There might be cases where rule #1 will be prohibitive from a
performance perspective. However, schema changes like that should be
rare to begin with, and should have prominent discussion on this list.
In the case where it's impossible to follow rule #1, it is still
critical to write scripts to roll back to the pre-change state.
3. For anything that involves a schema change to the production dbs,
make sure Asher Feldman (afeldman(a)wikimedia.org) is on the reviewer
list. He's already keeping an eye on this stuff the best he can, but
it's going to be easy for him to miss changes in extensions should
they happen.
I don't have a strong opinion about whether we need to follow rule #1
above through an iteration of our six month tarball release cycle, but
we at least need to follow it through the two week deployment cycle.
Assuming this seems sensible to everyone, I can update this page with this:
http://www.mediawiki.org/wiki/Development_policy
(/me desperately tries to avoid yak shaving and updating the policy
above for Git)
Rob