Development policy/Until 2018

''Some of this information may be outdated or incorrect. If you are familiar with the topic, please attempt to bring this article up to date.''

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.

Subversion access
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, and it will be granted in most cases. If you just intend to maintain language files, 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).

Unstable, the test server, and the REL* branches
Main development takes place in the main trunk of Subversion. That means you don't have to think about branches unless you are directly involved in maintaining releases.

The Test-Wiki was manually updated in the past to the latest unstable version so that new and experimental features could be tested. This is disabled as of 2005.

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 candidate, a 1.x.0 version, and finally a few minor bugfix releases.

The live wikis are updated to the latest released version regularly. If something goes wrong, change the subversion code in the current REL* branch, not the live wiki code, so that all wikis can be updated accordingly.

Releases
Every couple of 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. Our official recommendation, however, should be to always use the latest stable subversion branch.

Committing to subversion unstable
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.

Database patches
If the database is changed, a patch should be created, stored in maintenance/archives, and the file patch-list.txt in the same directory updated. In the future, it would be desirable to have the application of the patches during an update performed automatically by update.php.

Test server policy
For security reasons, there is no longer a test server within the Wikimedia server farm; however, there are various public test installations you can play with, such as http://test.leuksman.com

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 the Meta-Wikipedia), 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.

Documentation policy
If a feature is going to be visible to end users or administrators, the developer must document the feature on the MediaWiki User's Guide. 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.