Development policy/Until 2018: Difference between revisions

The MediaWiki software is developed collaboratively by hackers from all around the world. To make sure that none of our dozens of wikis breaks by an upgrade, but to also make sure that all our wikis are reasonably up-to-date, we need a general development policy. This is outlined here below.

Our current policy for handing out Subversion access is very liberal. If you have made meaningful contributions (by submitting patches, preferably as attachments to bugs in our Bugzilla tracker), you can apply for Subversion access (see Commit access requests), and it will be granted in most cases. If you just intend to commit and maintain an extension you've written, Subversion access can be granted even without prior participation in development. Subversion is a lot like wiki: Everything can be reverted. On the other hand, Subversion should be kept in a consistent state, especially the stable version (see below).

Main development takes place in the main trunk of Subversion, it is unstable, however should always be kept in a working state. Major modifications should take place in a development branch or elsewhere.

Code is generally synced from Subversion main trunk with the Test Wikipedia before it goes live on production sites, this is to ensure that everything isn't taken out by the update. It is important to remember that this is not a substitute for testing and all code should thoroughly be tested before being checked into Subversion trunk.

If you care about release management or want to try out one of the stabilized versions, the only branches that matter are those of the form REL*. All others, including "stable", are merely kept around to preserve the Subversion history.

Typically there will be a testing phase when a new release is begun. At that point users will be pointed to test.wikipedia.org to try out all the new things. There might be a few release candidates, a 1.x.0 version, and finally a few minor bugfix releases.

Every few months, the stable branch should be packaged into a .tar.gz file and made accessible from the webserver. This ensures that users of our software can easily get a reasonably stable version without messing with Subversion. Anyone submitting patches should preferably use the latest version of trunk to avoid conflicts, and of course people with commit access need to use Subversion to be able to commit stuff. It's not advisable to run production wikis off of development versions unless you know what you're doing (as do, for instance, the Wikimedia tech staff, a number of whom are also MediaWiki developers).

The Release checklist provides a more comprehensive list of tasks to be done for a release.

Even the unstable version should at least be runnable at any given time; that is, no scripts should throw fatal errors. Minor bugs can be worked out over time, but please test everything locally before committing. Also, while committing the unstable version, you should mention that your code needs fixes, this will help in reviewing it.

If the database schema is changed, remember to follow the following rules:

• Update the installer - Please update includes/installer and add an appropriate SQL update file to maintenance/archives/. Look at the commit history of includes/installer/(MySQL|Postgres|SQLite)Updater.php to find examples of how it's done.
• Get your change approved by a DB admin - MediaWiki is deployed to Wikimedia websites every two weeks, and it takes considerable planning to apply schema changes to MySQL-based sites the size of Wikipedia. As of this writing, Asher Feldman (afeldman@wikimedia.org) is the best person to add to database reviews.
• Make your schema change optional - All schema changes must go through a period of being optional. A couple examples:
  • 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. If this doesn't seem feasible, send mail to wikitech-l asking for advice.
  • You could set your new feature to only work if a config option is set to true, for instance, and set the option to false by default. Then the commit can be safely scapped before the schema change is made. You'll then have to pester the sysadmins incessantly to get them to make the schema change, at which point you can remove the config option to enable your feature.

There might be cases where the "make your schema change optional" rule will be prohibitive from a performance or logistics 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 make your schema change optional, it is still critical to write scripts to roll back to the pre-change state.

There is an official test server at http://test.wikipedia.org. Some developers may also have test servers deployed.

Generally, the purpose of such "fresh from Subversion" servers is to test the latest unstable branch of the code, not to have a testbed for demonstrating unfinished features. Features should be demonstrated with GUI mock-ups before they are implemented (these can be uploaded to Wikimedia Commons (preferred) or to this wiki), and implementations should only be committed to Subversion if they are in a reasonably complete state. This ensures that we avoid features that are never finished. To test your own code, please make sure you have a fully working local MediaWiki installation; if you want others to test your unstable code, you can always set up your own test server.

If a feature is going to be visible to end users or administrators, it's nice if the developer documents the feature on this wiki. Just a few sentences are fine: what it does, how to use it. Others will fix your prose up -- the important part is to have features documented. There are various templates available on this wiki using which you just have to edit a few lines & the template will handle everything else. If you're too lazy, on the other hand, it seems that plenty of people are willing to do it for you (yay wikis).

• How to become a MediaWiki hacker

• MediaWiki Development
• Policy