History:Migration Guideline

MusicBrainz Migration Guidelines

The MusicBrainz Migration Guidelines describe the process that is required for a change to get implemented on the server. These are currently (2005-12) under development and not compulsory yet

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

Hard Structure Changes

Means actual changes to the DatabaseSchema. This does not need to be big. Changes in AdvancedRelationshipTypes and AdvancedRelationshipAttributes are already HardStructure.

Soft Structure Changes

Mean changes in the way data is stored in the database. A StyleChange like the FeaturingArtistStyleAlternative can have massive impacts on the structure of the data. If a client expects the old structure, it could fail 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 consequences might lie far away (e.g. in the way the MusicBrainzTagger works) and are difficult to anticipate, let even to 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 dammage.

• There are special guidelines for StyleChanges: The ChecklistForStyleChanges

• HardStructure changes require BetaTesting. This means that the new sever software and database schema are loaded on the TestServer, and people try to find out whether thigs work, or if there are bugs left. Depending on the specific change, BetaEditing might be required, too.
• Finally the MetaBrainzCustomers need a TwoWeekMigrationPeriod for all HardStructure changes (actually this might exclude pure additions, so this might be rephrased to "for all Schema changes").