History:Migration Guideline

The MusicBrainz migration guideline describes the process that is required for a change to get implemented on the server. This are currently (2005-12) under development and not compulsory yet.

Changes can be divided into two categories: SoftStructure changes and HardStructure changes.

Hard Structure Changes

This means actual changes to the DatabaseSchema. Those do not need to be big. Changes in Advanced Relationship Types and AdvancedRelationshipAttributes are already HardStructure changes.

Soft Structure Changes

This means changes in the way data is stored in the database. A style change like the FeaturingArtistStyleAlternative can have massive impacts on the structure of the data. If a client expects the old structure, it could cease working, just because of such a SoftStructure change.

Both kinds of change need to be tested extensively before becoming live/official. The difficulty with SoftStructure changes is, that the impact might not be readily apparent (e.g. in the way the MusicBrainzTagger works) which can be difficult to anticipate, yet less imagine.

• Big SoftStructure changes require BetaEditing. This means that people apply a new StyleGuideline to data on the TestServer, and try to use it. People should try to do controversial changes. This way we can find out about implications of the change before it goes live and does a lot of damage.
• There are special guidelines for style changes: the ChecklistForStyleChanges.
• HardStructure changes require beta testing. This means that the new sever software and database schema are loaded on the TestServer and people try to find out whether things work or if there are bugs left. Depending on the specific change, BetaEditing might be required, too.
• Finally the MetaBrainzCustomers need a two week migration period for all HardStructure changes (actually this might exclude pure additions, so this might be rephrased to "for all Schema changes").