Development policy/Until 2018

The Wikipedia 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.

CVS access
Our current policy for handing out CVS access is very liberal. If you have made meaningful contributions (by submitting patches, usually to the wikitech-l mailing list), you can apply for CVS access, and it will be granted in most cases. If you just intend to maintain language files, CVS access can be granted even without prior participation in development. CVS is a lot like wiki: Everything can be reverted. On the other hand, CVS should be kept in a consistent state, especially the stable version (see below).

Unstable, the test server, and the stable branch
There are two development branches: unstable and stable. The unstable branch is the default CVS branch -- everything you commit to CVS goes there first. The Test-Wiki is regularly (currently manually) updated to the latest unstable version so that new and experimental features can be tested.

Features should be tested depending on complexity for 3-10 days. After they have been tested, they can be committed to the stable branch. Currently this is done by simply merging all unstable code into stable after a period of code inactivity (e.g. if development has cooled down, and the new features have been tested, stable becomes the latest unstable version). In special cases like bugfixes, it may be desirable to check features into stable separately -- but changes always need to be checked into unstable first. This is important so that branch consistency can be maintained.

The live wikis are updated to the latest stable branch regularly. If something goes wrong, change the CVS code in stable and/or unstable, 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 CVS. Our official recommendation, however, should be to always use the latest stable CVS branch.

Committing to CVS 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
The test server should always be updated from CVS. Its purpose 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 CVS 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 Wikipedia installation.

A separate script installation talking to the test database such as Tim's version is probably okay for public demonstrations of stuff that pretty much works, but a private test install is highly recommended for code that you're just starting on.

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.

See also: Development tasks