Release Process

From MusicBrainz Wiki
Jump to navigationJump to search

Note: This is a proposal. Not all of this process has been adopted yet.

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 - 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 (
  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.

Schema change releases

These branches do require scripts to be ran and our customers to also do some work on their end. We aim to have 2 of these releases a year, traditionally in May and October. For example, these changes might introduce new entity attributes, or restructuring of our database. In this case, the testing process is slightly different, as it won't be possible to test these features against a live database server.


  1. An author begins their work with a new branch, branched off master. When work goes into code review, it will be available for testing at the same time of code review.
  2. Here it needs more testing. The author does more hacking and creates more commits, and then pushes out a code review and updates the test branch at the same time.
  3. Users are happy with the new features, and code review has passed, so this work is ready to be "shipped." Usually, work would be shipped directly to master, but this is not possible for schema change features. Instead, we accumulate finished work in a master/schema-change branch. We make this separation because it allows us to keep doing weekly releases, without disrupting customers.
  4. This is an example of a release that happens in between schema change work. Notice that the schema change work has nothing to do with this commit.
  5. When the schema change release date finally comes, the master/schema-change branch is merged in master, and the schema change release is finally deployed to the main servers.