Release Process

MusicBrainz has a fairly intricate process when it comes to integrating new features into our codebase. There are fundamentally 2 different types of branches: schema change branches and non-schema change branches. These branches have different workflows, both of which are documented below.

Non-schema change releases

These branches are usually improvements to the website, which change user interaction, but don't require any fiddling with our database. Importantly, these branches will not require data customers to change their workflow.

1. Work begins with a developer creating a new branch. This branch is forked from the master branch, which is considered the most stable commit.
2. Several commits later, the author is happy with his work. However, it hasn't undergone any peer-review and must first be reviewed for code integrity. This is a check that makes sure that this code doesn't do any thing crazy, and reduces the risk of data corruption. While the branch is in this state, users can also do some testing on http://test.musicbrainz.org - a perfect time to discuss on IRC if the feature is at all useful, and matches the users expected interaction model.
3. In this example, the code review failed, so the author had to do more work, and then push the branch out for code review.
4. The code review has passed, meaning that developers are happy with quality of code. However, users might not be happy with the actual interaction process, so it needs to go in for user testing. This testing happens against the live database, but on a separate website (http://beta.musicbrainz.org)
5. Finally, both user testing and code review have passed and the community is happy with the feature. It's now merged into master, and will be part of the next server release.